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Ammunition  expenditures  emerging  from  high  level  'as  oooosed  to  h;gh 
resolution)  war  games  have  traditionally  been  either  unconstrained  or 
based  on  a  percentage  of  an  "anticipated"  daily  resupply  capability. 
Because  of  this,  support  analyses  have  not  been  the  product  of  a 
concurrent  logistics  simulation  utilizing  the  same  scenario,  but  have  been 
based  on  evaluations  made  after  game  completion.  This  method  can  paint  a 
false  picture  of  a  combat  unit’s  effectiveness.  The  logistics  system, 
esDecially  its  ability  to  resupoly  critical  cormodit'es  such  as  amnunit'on 
and  fuel,  must  be  evaluated  during  the  course  of  the  simulated  batfe. 

The  study  directive  for  the  Division-36  study  called  for.  a  Force 
Structure  Trade-off  Analysis  (FSTA)  of  various  division  alternatives.  The 
tool  for  this  FSTA  effort  was  the  Jiffy  war  game.  To  derive  meaningful 
insights  into  the  effects  of  the  ammunition  resupply  assets  contained  in 
the  different  force  structures  and  their  impact  on  the  combat 
effectiveness  of  the  various  units  within  the  division,  ammunition 
resupply  must  be  evaluated  in  some  detail.  Such  an  evaluation  must 
include  simulating  the  time-consuming  resupply  process  that  places 
ammunition  on  individual  weapon  systems,  as  well  as  the  movement  of  the 
different  units1  transportation  assets  to  secure  additional  ammunition. 

It  is  this  concept  that  provides  the  basis  for  the  Ammunition  Resupply 
Model  (ARM),  a  concept  that  reflects  the  real-world  factors  that  affect 
ammunition  resupply.  ARM  was,  therefore,  developed  to  work  in  parallel 
with  Jiffy  in  conducting  a  total  FSTA  of  the  Division-36  alternatives. 

The  concept  for  ARM  was  developed  in  Oct-Nov  1978,  with  the 
methodology  and  logic  flow  charts  being  completed  in  Dec  1973.'  The  actual 
coding  of  the  model  was  accomplished  from  Dec  1978  through  Feb  1979,  and 
the  model  was  Operational  in  May  1979.  This  report  provides  the  detailed 
documentation  of  t'he  methodology  and  operator  procedures. 

The  authors  of  this  report  wish  to  acknowledge  Harry  Jones  of  the 
Model  Design,  Development  and  Validation  Branch  of  COA  for  his  assistance 
in  programing  several  of  the  operating  routines.  Our  thanks  also  to  Mr. 
Ken  Pickett,  Dr.  Dave  3ash,  and  Mr.  Harvey  Taylor  of  Methodology  and 
quality  Assurance  3ranch  for  their  help  in  providing  some  initial  file 
structure  organization  and  programing  logic  flow  charts.  Special  thanks 
are  given  to  Mrs.  Elizabeth  Etheridge,  who  served  as  Technical  Editor  for 
this  report,  and  the  girls  in  the  Word  Processing  Center  East,  who  typed 
the  report. 
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Ammunition  Resupply  Model 
Technical  Manual 


1.  INTRODUCTION. 

a.  purpose.  The  purpose  of  tn-'s  report  is  tc  provide  a  aeta-'led 
description  of  the  Ammunition  Resupply  Model  (ARM).  ARM  was  developec  to 
operate  in  parallel  with  the  JIFFY  war  game  (but  it  is  adaptable  to  most 
other  combat  models).  ARM  has  been  used  with  JIFFY,  to  study  the 
ammunition  resupply  capability  of  alternative  division  organizations 
developed  for  evaluation  in  the  Division  86  force  structure  tradeoff 
analysis  (FSTA)  efforts. 

b.  Scope.  This  report  discusses  the  methodologies  and  data  used  in 
ARM  along  with  the  output  (reports)  generated.  Included  in  this  report  as 
appendix  A  is  the  Operators  Manual,  which  outlines  the  procedure  to  be 
followed  by  the  model  operator  in  the  execution  of  ARM. 

2.  0VERYIEW. 

a.  General.  ARM  is  an  event  oriented,  time  sequenced  computer  model 
developed  to  simulate  the  various  functions  associated  with  ammunition 
resupply  from  the  Corps  Storage  Area  (CSA)  down  to  the  individual  weapon 
systems.  Its  purpose  is  to  assess  the  capability  of  a  given  TOE  structure 
to  respond  to  the  logistical  demands  placed  upon  it  by  various  anmunition 
expenditures  developed  by  JIFFY  (and  is  easily  adapted  to  any  other 
model).  It  places  these  expenditures  as  demands  on  the  resupply  network. 
For  a  detailed  description  of  JIFFY  see  references  1  and  2.  ARM  forces 
the  network  to  replace  rounds  on  individual  weapon  systems  at  unit  level 
and  send  unit  trucks  back  to  designated  resupply  points  to  fill  up  and 
return.  The  functions  each  truck  must  perform  are  broken  into  a  series 

of  discrete  events  (subroutines).  The  model  takes  each  truck  through  a 
series  of  these  event  subroutines  (with  operational  availability  and 
interdiction  considered)  in  which  actions  are  completed  and  times 
accumulated.  Helicopter  resupply,  interactive  conmand  decisions,  and 
tactical  realism  can  be  incorporated  during  the  game. 

b.  Gamer  Functions.  The  manual  functions  associated  with  ARM  are 
the  finalizing  of  the  data  base  from  acquired  map  data  for  each  game 
played  and  the  interactive  operation  of  the  console.  The  map-acquired 
data  needed  to  finalize  the  data  base  are  the  locations  of  all  units,  the 
locations  of  the  Anmunition  Transfer  Points  (ATP)  and  Ammunition  Supply 
Point  (ASP),  and  the  road  distances  from  the  units  to  the  servicing  ATP 
and  ASP.  The  operating  instructions  are  contained  in  appendix  A. 

c.  Game  Resolution.  ARM  is  a  high  resolution  game  that  is  capable  of 
playing  a  brigade  or  division  size  force.  Through  the  development  of  a 
second  data  base  it  car  o’av  a  second  division,  thus  having  aop'icat'or  tc 


coros  ’eve  I  war  games.  Wit.nin  the  data  base  the 
cor-esoonds  to  that  of  J I FFY ;  that  is,  maneuver 
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d.  Stand  Alone  Model .  ARM  was  developed  as  a  stand  aione  mode1  4n 
order  to  retain  the  flexibility  to  support  other  attrition  mode’s. 

Ammunition  resupply  parallels  the  combat  that  generates  demands.  Resupply 
functions  take  place  concurrently  with  combat  and  continue  long  after  a 
particular  battle  has  been  fought,  ARM  is  an  event  sequencing,  time 
stepped  model  that  schedules  events  to  occur  in  future  time.  Consequently, 
it  should  not  be  integrated  into  the  attrition  model  that  ARM  is  supporting. 

3.  ASSUMPTIONS  AND  LIMITATIONS. 

a.  Maneuver  units  will  have  the  opportunity  to  accomplish  reload  once 
during  a  specified  period  (A  hours)  of  combat. 

b.  Artillery  units  will  reload  when  low  on  anrounition,  which  is  likely 
to  be  once  each  hour  during  the  battle. 

c.  Aviation  units  will  reload  upon  the  return  of  the  aircraft  to  the 
FARP. 


d.  Air  defense  artillery  units  will  reload  once  during  a  specified 
period  (4  hours)  of  combat. 

e.  Anrounition  trucks  are  dedicated  to  carrying  specified  types  of 
ammunition.  Limited  dual  loading  takes  place. 

f.  When  a  weapon  system  is  lost  all  anrounition  on  the  system  is  lost. 

g.  When  a  loaded  truck  is  interdicted  the  load  is  lost. 

h.  Helicopter  emergency  resupply  will  support  only  155nro  artillery 
batteries. 

i.  Helicopter  resupply  will  originate  from  the  ASP. 

j.  The  division  slice  of  corps  heavy  lift  helicopters  will  not  exceed 
10  CH47  s . 

k.  The  division  slice  of  corps  transportation  assets  for  ammunition 
resupply  will  be  one  medium  truck  company  of  60  tractors  and  120  trailers. 
This  company  will  provide  anrounition  through-put  from  the  Corps  Storage 
Area  (CSA)  to  the  ATPs  and  provide  some  replenishment  to  the  ASP. 
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1.  The  model  addresses  the  movement  of  anmunition  from  the  Corps 
Storage  Area  (CSA)  forward  to  the  individual  weapon  systems. 

4.  DATA  3ASE  DEVELOPMENT. 

a.  General .  The  aata  base  is  the  nucleus  of  ARM.  It  contains  a  un-'t 
xile  that  aescribes  various  attributes  of  each  unit  identified  in  the  force 
file  of  the  combat  game.  There  are  ATP  and  ASP  files  that  describe 
stockage  levels  of  ammunition  and  the  operating  characteristics  of  each.  A 
truck  file  that  describes  each  anmunition  truck  in  the  various  units  as 
well  as  the  stake  and  platform  (S6P)  trucks  of  the  corps  median  truck 
company  is  a  necessary  ingredient.  The  data  base  also  contains  an 
anmunition  file  that  identifies  different  truck  load  quantities  by  type  of 
ammunition  and  the  load  times  at  the  ATP  or  ASP  for  the  respective  quantity 
of  rounds.  The  information  to  make  up  the  data  base  came  from  the  TOEs  of 
the  units  played  in  the  war  game  as  well  as  from  FM  101-10-1,  the 
Ammunition  Initiative  Task  Force  (AITF)  Report,  the  Ammunition  Transfer 
Point  (ATP)  Test  Report,  and  several  TRADOC  associated  schools. 


b.  Definition  and  Description  of  Data  Files. 

(1)  IUNIT  File.  The  IUNIT  file  consists  of  a  75  by  69  array  in  which 
each  unit  is  listed  using  up  to  69  attributes  to  describe  each.  Most  of 
the  attributes  are  used  to  describe  up  to  five  types  of  anmunition  that  a 
unit  might  use. 

(a)  Attribute  1  identifies  the  type  of  unit.  There  are  presently 
eight  different  unit  codes  as  shown  in  figure  1. 


1 

2 

3 

4 

5 

6 

7 

8 


Tank  task  force 
Mech  task  force 
Armed  cav  sqdn 
155  arty  btry 
8  inch  arty  btry 
GSRS  btry 
DIVAD  gun  btry 
Cbt  avn  bn 


Figure  1.  Unit  Type  Codes 
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(b)  Attributes  2  and  3  identify  the  servicing  ATP  and  ASP  of  the  unit, 
while  attributes  4  and  5  provide  the  distance  from  the  combat  trains  or 
assembly  area  to  the  ATP  and  ASP.  Attribute  6  identifies  the  unit's 
position  on  the  map,  and  attribute  7  contains  the  name  of  the  unit  such  as 
TF4A  as  used  in  the  attrition  model.  The  name  of  the  unit  in  ARM  must  be 
identical  to  that  in  the  war  game  generating  the  expenditure  data. 
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(c)  Attributes  3  through  57  are  used  to  describe 
associated  with  the  unit's  'najor  weaDon  systems.  Attr 
the  first  airmun ,:t’on  tyoe  as  follows: 


the  antnun;t'on 
■butes  3-13  descr-be 


1.  Attribute  3  identifies  the  first  ammun-t'on  tyoe. 
■,ar,c"*’e  13  S''"ra,*e,it  tyoes  : *  atmun :~.3 tn  it  :,'ese''t,  t-cs? 
tangv,acr!  A-/-2 2  tr*  Annex  A-/. 


■-e  node’  tan 


2.  Attribute  9  lists  the  number  of  weapons  alive  that  use  the 
ammunition  identified  in  Attribute  3. 


2*  Attribute  10  shows  the  number  of  weapons  that  are  short  amnunition 
at  the  end  of  a  Cl. 

4.  Attribute  11  lists  the  number  of  rounds  short  of  this  type 
ammunition. 

5.  Attribute  12  shows  the  current  ammunition  supply  on  the  weapons, 
whicF  is  equal  to  the  basic  load  on  the  weapons  alive  minus  the  rounds 
short. 


6.  Attribute  13  identifies  the  routine  resupply  level;  i.e.,  that 
leveT  of  ammunition  stockage  on  the  weapon  at  which  resupply  would  be 
initiated  given  an  opportunity  to  resupply. 

7.  Attribute  14  identifies  the  critical  resupply  level;  i.e.,  that 
leveT  of  ammunition  stockage  on  the  weapon  at  which  resupply  must  be 
initiated  in  order  to  sustain  firing. 

8.  Attribute  15  is  the  basic  amnunition  level  (per  weapon).  It  lists 
the  stockage  of  amnunition  on  the  weapon  system  itself  and/or  the  track 
carrier  associated  with  an  artillery  tube. 

9.  Attribute  16  is  the  ammunition  on  trucks.  It  lists  the  number  of 
rounds  bulk  loaded  on  the  unit  amnunition  trucks.  It  represents  the  bulk 
loaded  portion  of  the  true  basic  load. 

10.  Attribute  17  is  the  number  of  weapons  killed  at  the  end  of  the 

critical  incident  (Cl).  This  is  an  input  from  the  war  game  each  Cl  and  is 

used  to  reduce  the  original  number  of  weapon  systems  alive. 

11.  Attribute  13  is  the  number  of  weapons  short  ammunition  during  the 

Cl.  “Tt  Is  used  to  determine  reload  requirements  per  weapon  based  upon 

total  rounds  short. 

12.  Attribute  19  is  the  total  rounds  fired  through  the  whole  Cl.  It 
is  an  input  from  the  war  game  each  Cl  and  is  used  as  the  demand  on  the 
resupply  network. 
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(d)  Attributes  20-57  describe  the  other  four  types  of  anmunition  used 
by  a  particular  unit.  In  describing  a  GSRS  unit  only  attributes  S-19  would 
be  used  since  only  one  type  of  anmunition  is  *ired. 

(e)  Attribute  68  is  the  number  of  helicopters  assigned.  It  applies 
on'y  to  155nm  artillery  units  and  is  used  to  determine  wnether  or  net  a 
un-t  has  received  the  maximum  of  two  helicopter  '■esuDp'y  missions  this  01. 

(f)  The  last  attribute  (69)  contains  a  0  or  a  1.  A  0  indicates  that 
the  unit  receives  a  single  pulse  demand  per  Cl;  that  is,  reload  of  rounds 
fired  is  accomplished  once  during  the  Cl.  A  1  indicates  that  the  unit 
receives  multiple  pulses  during  the  Cl.  For  example,  for  artillery  units 
the  total  Cl  demand  is  divided  in  fourths,  with  l/4th  the  demand  being 
resupplied  each  hour.  A  sample  of  a  unit  file  is  shown  in  figure  2. 

(2)  ITRUCK  File.  The  ITRUCK  file  consists  of  a  560  by  7  array,  which 
allows  the  use  of  560  trucks,  each  of  which  is  described  by  seven  words  as 
f o 1 1 ows : 

(a)  -Attribute  1.  Truck  type  -  six  truck  types  are  used  in  the  model 
as  shown  in  figure  3. 

Code  TRK  TYPE 

1  -  10  Ton 

2  -  5  Ton 

3  -  5  Ton  w/1  1/2  T.  Trl. 

4- 10  Ton  w/15  T.  Trl. 

5- 22  1/2  Ton  Stake  and  Platform 

6  -  Helicopter,  CH  47 

Figure  3.  Truck  Type  Codes 


(b)  Attribute  2.  Mission  type  -  identifies  the  truck  as  a  unit  truck 
or  a  truck  used  on  the  CSA  to  ATP  link,  or  ASP  to  ATP  link.  There  are 


presently  five  mission  type  codes  as 

(c)  Attribute  3.  Status  type  - 
based  upon  the  status  codes  shown  in 

COPE 

1 

2 

3 

4 

5 

6 


listed  in  A-V-23  of  annex  A-V. 

identifies  the  status  of  the  truck 
figure  4. 

DEFINITION 

IN  UNIT  QUEUE 
IN  ATP  QUEUE 
IN  ASP  QUEUE 
IN  TRANSIT 

UNIT  TRUCK  GOING  FROM  ATP  TO  ASP 
TRUCK  AWAITING  REPAIR 
TRUCK  DEAD  (INTERDICTED' 


Figure  A. 


Truck  Status  Codes 
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Figure  ii.  IUN i T  rile 


(d)  Attribute  4.  Owner  number  -  the  ARM  number  for  a  particular 
unit;  e.g.,  10,  33,  45. 

fe'  Attribute  5.  Anvnc  mix  number  -  the  number  that  identifies  the 
type  of  ammunition  hauled  Dy  the  truck  (see  figure  5). 

(f)  Attribute  6.  Dercent  loaded  -  the  percent  0*  anmunition  on  the 
truck  at  a  given  point  in  time. 

(g)  Attribute  7.  Time  since  last  failure  -  contains  the  time  since 
the  truck  last  had  a  failure.  It  is  used  to  determine  the  next  time  the 
truck  will  break  down  by  subtracting  from  it  all  subsequent  movement 
times.  It  is  established  for  all  trucks  at  the  beginning  of  the  game  by 
multiplying  the  mean  time  between  failure  of  each  type  of  truck  found  in 
ITYPE  by  a  random  number  between  0  and  1,  thus  distributing  the  time  since 
the  trucks  were  last  repaired. 

(3)  ITYPE.  This  is  a  6  by  6  array  used  to  describe  each  of  the  six 
types  of  trucks  as  follows: 

(a)  Attribute  1.  Secondary  road  night  speed  in  km/hr  -  used  in 
determining  arrival  time  of  a  unit  truck  traveling  to  the  ATP  or  ASP  at 
night. 

(b)  Attribute  2.  Secondary  road  day  speed  in  km/hr  -  used  in 
determining  arrival  time  of  a  unit  truck  traveling  to  the  ATP  or  ASP  during 
the  day. 

(c)  Attribute  3.  Highway  night  speed  in  km/hr  -  used  in  calculating 
the  arrival  time  of  an  S&P  truck  traveling  at  night. 

(d)  Attribute  4.  Highway  day  speed  in  km/hr  -  the  speed  of  an  S&P 
truck  on  a  highway  during  the  day. 

(e)  Attribute  5.  Mean-tlme-between-failure  (MTBF)  in  minutes  -  used 
to  address 'operational  availability  of  the  trucks. 

(f)  Attribute  6.  Mean-time-to-repair  (MTTR)  in  minutes  -  used  to 
determine  the  time  that  a  truck  will  return  to  duty  once  it  has  broken  down. 

(4)  IRSTME.  A  20  by  3  file  that  records  resupply  time  data  for  20 
types  of  ammunition.  Each  anmunition  type  is  described  as  follows: 

(a)  Attribute  1.  Weapon  set-up  time  -  the  time  it  takes  a  weapon 
system  to  prepare  itself  to  take  on  ammunition  once  the  ammunition  truck 
arrives  in  the  area  of  the  weapon. 

(b)  Attribute  2.  Load  time  per  round  the  average  time  to  uncase  a 
-ound  and  store  it  on  the  weapon  system. 
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':)  Attribute  3.  Trave’  tine  to  weapon  -  the  one-way  trave1  t-'me  *-cm 
the  truck  assemb’y  area  or  combat  trains  to  the  weapon  system  'ocat-on.  It 
is  computed  cased  on  the  approx ' mate  distance  that  the  trucks  are  ’'ke’y  to 
oe  from  the  weapons  systems  they  support  and  the  travel  soeec  of  the 
truck,  ’he  crave"  speed  ;s  oa’c-Tatad  as  toe  average  soeec  _'or  53  ce^cent 
ird  ” ?  '*c -d s .  ***  v/  1  “ r ^ 

ca'cu'aceo  oaseo  ,o  on  noo'"‘ty  data  sonta^eo  -i  -'c  c  •'  *  • :  /  -er-ormarce  ;■ 

1/ --  to  13-  ’on  ’act'oa*  ~ruc.<s  and  Cargo  3arv-'ers  :n  toe  -I.MC  «esc  Sermany 
Study  Area  (TACV  Study)  produced  by  US  Army  Engineer  Waterways  Experiment 
Station,  reference  3. 


(5)  IASP.  This  is  a  4  by  41  word  array  that  describes  the  Anmunit’on 
Supply  Point.  The  model  can  handle  four  ASPs,  each  of  which  is  identified 
by  33  attributes.  The  other  attributes  are  currently  empty.  This  file 
contains  the  current  stock  age  of  amnunition  played  in  the  model  and  the 
number  of  servers  available  to  load  unit  trucks.  There  is  a  separate  queue 
for  GSRS  trucks  and  one  for  all  other  trucks.  Since  GSRS  trucks  have  thei’" 
own  self  loader  it  is  assumed  that  no  assistance  ,;s  ^equi^ed  from  the  ASP 
crew.  There  is  also  an  attribute  that  keeps  track  of  the  number  of  trucks 
in  each  queue.  See  paragraph  A-V-5  of  annex  A-'/  for  a  description  of  each 
attribute. 


(6)  IATP.  This  is  a  4  by  30  array  that  describes  four  separate  ATPs. 
Each  ATP  is  defined  by  the  30  attributes  listed  in  paragraph  A-V-3  of  annex 
V.  Under  the  ATP  concept,  it  would  handle  high  demand-high  tonnage 
anmunition  with  155  HE,  155  ICM,  tank  and  TOW  being  the  recommended 

stock  age.  In  ARM  the  ATP  can  handle  five  types  of  anmunition,  the  four 
listed  above  and  155mm  powder.  The  powder  is  handled  separately  since  the 
S&P  trucks  from  the  CSA  will  be  commodity  loaded;  i.e.,  only  one  type  of 
load  per  truck,  no  cross  loading.  On  the  other  hand,  S&P  trucks 
originating  at  the  ASP  could  be  combat  loaded;  that  is,  loading  a  trailer 
with  two- thirds  white  bag  and  one- third  green  bag  powder. 

(7)  IMIX.  This  is  a  40  by  23  array  that  records  information  on  40 
different  combinations  of  ammunition  mixes.  For  each  of  the.  17  ammunition 
codes  used  in  ARM  the  IMIX  file  contains  one  or  more  mix  numbers.  Each  mix 
number  represents  the  number  of  rounds  of  that  type  ammuniton  that  can  be 
hauled  on  a  particular  type  truck.  For  example,  IMIX  22  represents  a  load 
of  96  rounds  of  155mm  ICM  on  a  5-ton  truck  with  trailer.  Attributes  22  and 
23  of  IMIX  22  provide  the  load  time  for  this  quantity  of  rounds  at  the  AT? 
and  ASP.  A  sample  of  the  IMIX  matrix  is  shown  in  figure  5. 

(8)  Other.  Other  files  or  data  conmons  required  are  defined  in  annex 

A-V. 


c.  Building  of  Data  Files. 

(1)  Main  data  files.  Although  editing  of  the  data  base  can  be 
accomplished  through  use  of  the  main  ARM  program  driver,  it  is  desirable 
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AM  no 


Figure  5.  IMIX  File 


and  more  advantageous  to  bui’d  the  initial  data  base  through  the  use  of  a 
seDarate  ed’‘t  orogram  cal’ed  ^nto  play  by  the  call  orogram  HJEDIT.  ~o  ed’t 
an  ax’St'ng  data  base  or  create  a  totally  new  one  it  is  ‘•>"st  necessary  *or 
the  ooerator  to  be  'egged  ’n  on  a  CR"  ender  a  10CK  oassworo.  “he  next  steo 
;s  to  attach  a  /ers;cn  of  -iOARMCA'A  as  "1.  -iCARMDATA  -'s  tne  oermanert  --'e 


'ame 


*-u 


e  raster 


oer*ormea  :n  orce? 


data  ! 
to  ec 


:ase.  ""e  ccmo’eta  secoence  r*  events 
:t  the  cata  case  ;s  as  *'o":ws: 


(a)  Attach  HOARMOATA  as  T1 

Attach,  Tl,  HOARMOATA, ID-TRACOMD 

(b)  Call  HJEDIT 

Call,  HJEDIT, ID*TRACOMD 

(c)  CUE:  EDIT  DATA  FILES?  (Yes/No) 

(d)  ANS:  "YES"  or  "Y" 

(e)  ENTER  VARIABLE  NAME  — 

(f)  ANS:  IUNIT  10  —  CUE:  Enter  the  name  of  anyone  of  the  various 

files  to  be  edited,  such  as  IUNIT  10.  This  will  allow  the  operator  to  make 
any  changes  to  the  attributes  of  IUNIT  10.  For  a  list  of  all  the  data 
files  and  their  attributes  see  annex  V  to  appendix  A. 


(g)  CUE:  .  . 

(h)  ANS:  L  8  19 

This  lists  the  attributes  8  through  19  that  describe  the  first  ammunition 
type  for  unit  10. 

(i)  RES:  IUNIT  10 

ATTRIBUTE  8  1 

ATTRIBUTE  9  36 

ATTRIBUTE  10  0 

ATTRIBUTE  11  0 

ATTRIBUTE  12  1944 

ATTRIBUTE  W  0 

(j)  CUE:  .  . 

Any  attribute  can  be  changed  by  writing  C  for  change,  I  an  integer 
representing  the  attribute  to  be  changed,  and  J  an  integer  representing  the 
new  value.  The  entry  would  look  like  this:  C  9  30,  which  means  change 
attribute  9  to  read  30.  If  the  same  values  are  to  be  entered  into  several 
units,  it  is  possible  to  make  these  changes  all  at  once  by  identifying  all 
the  units  as  follows:  IUNIT  1,  10;  Res:  any  changes  made  to  an  attribute 
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will  be  recorded  in  units  1  through  10.  More  discussion  on  the  cofimands 
that  can  be  used  in  editing  the  data  base  can  be  found  in  annex  I  to 
apoend’x  A.  Having  completed  making  all  the  ’-equired  changes  to  the  data 
base  the  word  "end"  is  entered  afte«-  the  C'JE:  .  \  is  given. 


'  k  • 

CUE: 

.  .  END 

(1) 

CUE: 

EDIT  DATA  FILE?  (YES/NO) 

(m) 

ANS: 

"N"  or  "NO" 

(n) 

CUE: 

UPDATE  ARRAYS? 

(o) 

changes 

ANS: 
to  the 

NO,  Response  NO  is  given  here  since  it  is  assumed  that  all 
data  base  have  been  made.  A  YES  response  would  allow  a  more 

rapid  change  of  selected  attributes  over  multiple  variables. 

RES:  The  edited  data  base  is  written  to  Tape  1  and  the  program 
terminates. 

(p)  The  original  T1  should  be  returned  and  TARE  1  copied  to  a  new 
local  file  T1  in  preparation  for  the  next  operation  to  complete  building 
the  data  base.  TAPE  1  can  be  returned. 

(2)  Truck  queue. 

(a)  General.  After  developing  the  data  base  is  it  necessary  to  assign 
all  trucks  to  their  respective  queues  (units).  In  the  ITRUCK  file  of  the 
data  base  the  trucks  were  assigned  owner  numbers  coinciding  with  the  ARM 
IUNIT  numbers.  In  order  for  the  model  to  find  these  trucks  it  is  necessary 
to  put  the  trucks  in  their  respective  queues.  All  trucks  assigned  to  owner 
10  must  be  put  into  queue  10.  Trucks  assigned  to  an  ATP,  which  have  on 
board  the  initial  stockage  of  anmunition  at  the  ATP,  must  be  put  into  the 
right  queue  at  the  various  ATPs.  Trucks  that  will  be  set  in  motion  at  the 
beginning  of  the  game  should  not  be  placed  in  a  queue.  This  is  any  truck 
assigned  a  status  code  4. 

(b)  Operator  routines, 

1_.  Continuing  from  the  previous  operation,  paragraph  4c(l)(0)  where 
TAPE  1  was  copied  to  a  new  Tl,  the  next  command  is  call  HJTRKQUE. 

2.  CALL,  HJTRKQUE, I D-TRACOMD 

3.  CUE:  Modify  Truck  Queues?  (Yes/No) 

4.  ANS:  "Y"  or  "Yes" 


11 


2*  ANS:  lommand  Examo’es: 

GET  3  ;”om  35 
3ut  3,  10  in  105 
■_ J  st  135 
~a.<e  i"  :uc 

-  nH 

—  ^ 

-  **•  i  #• 

0*  wwC i  •  • 

2*  ANS:  Enter  the  commands  to  accomplish  the  task.  If 

all  the  queues  are  empty  then  the  operator  can  begin  putting  the  various 
trucks  in  their  respective  queues;  i.e., 

P  70,  79  in  10— This  puts  trucks  70  through  79  in  queue  10, 
unit  10. 

P  501,  512  in  101 — This  puts  trucks  501-512  in  queue  101  at  ATP  1. 
If  an  old  data  base  is  being  modified  to  reflect  a  new  organization  it  may 
be  necessary  to  remove  certain  trucks  from  their  old  unit  queues  before 
they  can  be  put  in  their  new  unit  queues.  Trucks  must  be  removed  xrcm  a 
queue  one  at  a  time  (3  30  of  11)  unless  the  operator  enters  "Take  all  out", 
which  will  initialize  all  queues  to  zero.  After  entering  all  the  trucks  in 
their  respective  queues,  enter  END. 

3.  CUE:  .  . 

9.  ANS:  ENO 

10.  CUE:  Print  Out  Contents  of  Queues?  (Yes/No) 

11.  ANS:  "YES"  or  “Y" 

12.  RES:  Contents  of  all  queues  will  be  printed  to  output.  A  sample 
of  tTie  queue  listing  is  shown  in  figure  6. 

13.  CUE:  Modify  Truck  Queues?  (Yes/No) 

H.  ANS:  "NO"  or  "N" 

15.  CUE:  Print  Out  Contents  of  Queues?  (Yes/No) 

26.  ANS:  "NO"  or  "N" 

17.  RES:  New  queue  listing  and  all  data  base  files  are  written  to 
TAPET  and  program  terminates.  TI  should  now  be  returned  and  TAPE  1 
cataloged  as  the  new  Master  Data  Base  for  this  version  of  ARM.  Further 
discussion  of  the  subroutine  TRKPUT  can  be  found  in  annex  III  of  appendix 
A.  The  actual  computer  program  for  TRKQUE  and  associated  subroutine  can  be 
found  in  Volume  II,  Programers  Manual. 
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Queue  11  TRUCKS _ 

83  9C  91  92  33  9*  35  96  37  98 

39  12  0  101  132  133  13'-* _ 

Queue  12  truck  s _ 

105  106  107  103  109  113 


QUEUE  13  TRUCKS 
111. 112  113  111  115  115 

Queue  11  TRUCKS 
117  118  119  120  121  122 


Queue  is  trucks 

123  121  125  126  127  129 

Queue  16  TRUCKS 
.29  130  131  132  133  134 


QUEUE  17  TRUCKS 
135  136  137  133  139 


CUeug  13  TRUCKS _ 

140  141  142  143  144 

QUEUS  19  TRUCKS 

145  146  147  143  149  150  151  152  153  154 
•155 

Queue  20  TRUCKS  ’ 

156  157  158  159  160  161  162  163  164  155 
166 


QUEUE  21  TRUCKS 

157  153  169  i?;  ^7*  ^7?  173  i7l  its  <ri 

177  "  * 


FIGURE  S.  Truck  Queues 


XXX 


5.  METHODOLOGY . 


a.  lene-a’ .  'Me  general  concept  *or  z Me  ARM  3 ''ru’ at 4  on 
Hesc-'ov  ;n  y *  t Me  imrnunit43n  -esuoo'iy  :o  ■  4c''es  v4t.h':n-a  o4v4 
w'ci  c.ie  anmun;v  on  ohrojgn-cut  orovijed  ay  c.ie  ocros  o^occrc 
- 57 * j'/v  “ ”  to’  'a' as  “e^ea’a  a  a -1* 4  a !  ae  a4/'C'*a'ta  -'/ana* 


-,3  oaseo  an 
S' on  a'ong 
jn*'os.  a 

• . -3  - • -  -a 


a 


-rrrvjn •  v  or,  e.oerc'c^res  cu; — 'g  a  aata  e  aenenaae  a  cema.rc  *an  nc^a 
ammunition.  "he  ammuni ti on  crucxs  of  one  /ar4ous  jn'as  execute  *e__aaa 
activities  to  replenish  expended  rounds  on  surviving  weapons,  when  unit 
trucks  become  empty,  they  are  sent  to  a  rear  ammunition  resupply  point  for 
another  load.  The  amnunition  resupply  point  must  have  its  stock  age 
replenished  in  order  to  continually  support  the  combat  units.  Essentially, 
AftM  processes  the  ammunition  expenditure  developed  by  a  war  game  and  places 
this  expenditure  as  a  demand  on  the  resupply  network.  It  forces  the 
network  to  replace  rounds  expended  at  unit  level  by  requiring  unit 
anmunition  trucks  to  reload  the  surviving  weapon  systems  and,  when  empty, 
to  go  to  a  designated  resupply  ooint,  fill,  and  return.  The  model  takes 
each  truck  through  a  series  of  discrete  events  (subroutines'  (operational 
availability  and  interdiction  considered)  in  which  actions  are  completed 
and  times  are  accumulated. 


b.  Major  Events.  The  ammunition  resupply  network  was  broken  down  into 
four  major  events,  each  with  a  nuntoer  of  subroutines.  The  major  events  are 
demand,  reload,  resupply,  and  replenishment.  The  connecting  links  among 
the  last  three  events  are  the  anmunition  trucks  of  the  various  units  and 
their  movements.  Figure  3  is  a  graphic  view  of  the  event  subroutines  and 
should  be  referred  to  while  studying  the  description  of  each  subroutine. 


Flpir*  7.  WnunHIon  ftasupply  i«twrt 


:.  Demand.  “he  demand  *or  ARM  ^ s  orovrte d  as  an  •'n0ut  so  she  mode' 
•-om  some  oooosing  -orsas  van  game,  "he  "''out  1  * s 1 3  by  jn,-t  the  number  0* 
each  ^eaoon  systems  -ema ' n ’ no  a’'  /e,  sne  number  :•?  jjrv*  /ers  that  actua"/ 
*;^ed,  ana  tse  total  '•turds  s*  arnmurr-t'cn  *'’-ed  0 y  s^e.  surv-ve^s .  ’surds 
-•-ec  sy  systems  tnat  ^e^e  <-''ec  "!a/e  see''  Sjot^actec  tut. 

j  ~  *  n  i  3  M  *^p  “  -j  ^  j  *"  '  p  "**  I'JH  -  01*^  ^  v»>-h  a  *•  •  •  r*  c  ^  *  -«  p  -«  £  *•  z  ^  ^  n  >  / 

-ns a* ’ s* ;  tc  leffians  a  *  *  reroara  ; ~ a •  **  *$  :eer  3  a  v  $  ’  ‘  r :  :-a 

DEMAND  event  ;s  ca”ec'  and  :omc:.n*ng  ;t  w^to  newly  generated  cemanc.  I* 
the  unit  is  artillery,  the  total  demand  for  each  tyoe  of  aimunition  -’s 
divided  by  H  to  reflect  the  expenditure  during  each  hour  of  the  H  hour 
critical  incident  of  the  war  game  for  which  ARM  was  developed.  The 
subroutine  then  scans  the  trucks  at  the  unit  to  find  one  with  the  -ight 
aimunition.  In  the  particular  case  of  155im  artillery  units,  DEMAND 
compares  the  actual  demand  (expenditure)  against  the  sum  of  the  current 
supply  and  the  amo-on-trudcs.  If  the  difference  is  unusually  high  (e.g., 
no  trucks  at  the  unit  and  current  supply  low)  it  is  compared  against  the 
critical  resupply  level.  If  the  critical  resupoly  ’evel  has  been  reached, 
DEMAND  wi’l  schedule  an  emergency  "“load  event  by  he^icoDter  (HELARV'.  If 
a  truck  was  found  with  the  correct  aimunition  on  board  a  RELOAD  event  is 
scheduled.  (JDon  completion  of  the  DEMANO  event,  the  unit'.s.  demand  will 
have  been  updated  and  a  reload  event  scheduled.  For  artillery  units  the 
DEMAND  event  will  reschedule  itself  to  occur  again  50  minutes  from  the 
present  time. 

d.  Reload.  For  a  given  unit  for  which  reload  has  been  scheduled  the 
subroutine  & £L0A0  performs  the  actual  replacement  of  rounds  of  ammunition 
expended  by  rounds  carried  on  unit  trucks.  First  a  type  of  aimunition  is 
selected,  then  the  unit  queue  is  searched  for  a  truck  hauling  that  type  of 
aimunition.  If  a  truck  is  found,  the  following  calculations  are  made:  (1) 
the  number  of  weapon  systems  that  can  be  reloaded  by  this  truck  -  a 
function  of  the  demand  and  the  truck's  load,  (2)  the  total  reload  time,  and 
(3)  the  return  time  to  the  combat  trains  or  truck  assembly  area.  The 
reload  time  is  calculated  by  the  following  equation: 

Rtimeijk  «  2  *  Trvtmek  +  w(Ai  +  3j  (#Rds/Wpn))_ 
where  Rtime^jk  »  the  time  required  to  complete  reload  for 

weapons  i  with  round  j  at  unit  k. 

TRVTMEk  a  travel  time  from  combat  trains  or  truck 
assembly  areas  to  the  weapon  positions 

W  »  number  of  weapons  that  can  be  loaded  by  a  truck 
(depends  on  truck  load) 

*i  3  set  up  time  per  weapon  i  (time  for  weapon  to 
orepare  itself  to  take  on  ammunition) 
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3 


"e load  time  per  round  (obtained  from  IRSTME 

file) 


Having  completed  reload  o*  the  weapons  the  truck  is  schedu’ed  tc  '•eturn  t: 
the  combat  trains  o'*  assembly  area  if  there  are  rounds  on  board  o”  ’t  *s 
scnedu’ed  to  gc  o'ck  up  another  load,  “he^efo^e,  RELOAD  w'"  scnedu’e  a 
un*'t  ar-iva"!  'UNTARVl,  '•“turning  the  truck  to  the  un’:t  to  wa’t  *pr  another 
demand,  or  a  unit  departure  {UNTDEP),  sending  it  after  another  load. 

e.  Unit  Arrival  (UNTARV).  The  subroutine  UNTARV  brings  the  truck  back 
to  the  unit  combat  trains,  in  the  case  of  maneuver  units,  or  asseirfcly  areas 
for  artillery  units.  Upon  arrival  the  ammo-on-truck,  an  element  of  the 
unit  status,  is  updated.  Since  this  event  is  scheduled  from  other 
subroutines  a  check  is  made  for  unsatisfied  demand  of  the  particular  type 
of  anmunition  carried  on  the  truck.  If  there  is  an  unsatisfied  demand,  a 
RELOAD  event  is  immediately  scheduled;  otherwise,  the  truck  waits  for 
another  RELOAD  event  to  occur. 

f.  Unit  Departure  (UNTDEP).  If  upon  completion  of  a  reload  event  a 
truck  is. empty,  a  unit  departure  (UNTDEP)  event  is  scheduled.  This 
subroutine  checks  the  type  of  anmunition  the  truck  was  carrying  against  the 
four  types  of  ammunition  stocked  at  the  ATP.  If  a  match  in  ammunition 
codes  is  found,  an  arrival  time  at  the  servicing  ATP  is  calculated  and  an 
ATP  arrival  (ATPARV)  event  scheduled.  The  arrival  time  is  based  upon  the 
distance  from  the  unit  to  the  ATP  and  the  average  speed  of  the  truck.  If 
no  match  in  ammunition  codes  is  made  then  an  arrival  time  at  the  ASP  is 
calculated  and  an  ASP  arrival  (ASPARV)  event  scheduled. 

g.  Operational  Availability.  Every  time  a  truck  moves,  a  check  is 
made  of  its  operational  availability  in  subroutine  OPERA.  Each  truck  has 
its  own  clock,  which  keeps  track  of  the  hours  of  operation  since  it  last 
failed.  At  the  start  of  the  game  all  trucks  are  initialized  with  a  time 
since  last  failure.  This  initialization  is  the  product  of  the 
mean-time-between-failure  and  a  random  number  between  0  and  1.  Each  time  a 
truck  moves,  the  time  length  of  the  move  is  subtracted  from  the  time 
remaining  until  the  next  failure.  When  the  time  remaining  becomes  zero  the 
truck  status  is  changed  and  its  movement  delayed  by  the  mean-time-to-repai” 
for  the  particular  type  of  truck.  OPERA  is  called  from  any  event 
subroutine  that  involves  truck  movement. 

h.  Interdiction.  The  interdiction  subroutine  (INTRDK)  determines 
whether  a  truck  about  to  execute  a  move  will  be  interdicted  and,  if  so, 
assesses  a  time  delay  for  providing  a  replacement  truck.  For  interdiction 
purposes,  the  combat  zone  is  subdivided  into  two  zones-  Zone  one  extends 
from  the  line  of  contact  to  the  brigade  rear  boundary.  Zone  two  consists 
of  the  area  from  the  brigade  rear  boundary  to  the  corps  storage  area.  Unit 
trucks  forward  of  the  ATP  are  considered  to  be  in  zone  one,  where  they  are 
susceptible  to  being  hit  by  artillery  fire.  Unit  trucks  moving  from  the 


AT5  to  the  AS?  and  a!1  34?  type  trucks  are  considered  t:  rove  '.r  tone  two, 
where  they  are  subject  to  attacks  by  aircraft.  ”he  attrition  roce’ 
orov’des  the  number  of  trucks  Wed  by  arti”ery  ‘-'"e  dur-'rg  the  oatt'e 
oe’rg  3'ruiated.  In  order  to  determ’ne  wh-’cn  trucks  are  ;ntard'cted  ;t  ;s 
*''rst  recess  ary  to  :a.<a  the  total  lumper  of  trucks  <‘"ea,  as  g'/en  :y  ore 
attr't'on  rede’,  and  ru’t'o’v  Jt  b1/  the  oe^centace  o"  a'’  trucks  t^at  o 
a.Tmun  'O'  on .  ”V$  ru.Toer  *s  tren  entered  ;nto  a  oaoa  ";"a  as  ore  ooca' 

Tj.roer  of  tone  one  :ruc.<s  to  oe  ''nterdicced  t.vs  cattle  period.  In  oncer 
to  spread  this  number  over  as  many  units  as  possible,  another  number 
between  15  and  30  is  selected  at  random,  which  is  used  as  a  controlled 
cycle  number  that  we  will  call  y.  Each  time  a  truck  is  scheduled  for  move 
it  is  sent  through  INTRDK,  where  a  counter  is  maintained.  When  the  yth 
truck  enters  INTRDK  it  is  the  one  interdicted,  and  a  time  delay  is  assessed 
before  a  replacement  truck  can  be  provided.  The  counter  is  then  reset  to  0 
and  started  again.  This  procedure  is  continued  until  the  total  number  of 
trucks  that  were  to  be  interdicted  has  been  reached.  This  method  comes 
very  close  to  representing  reality  since  one  would  expect  that  units  that 
fire  often  are  more  susceptible  to  receiving  counterf’”®  and  therefore  lose 
more  trucks.  In  ARM  the  units  that  fire  more  require  the  unit  trucks  to 
move  more  frequently.  The  number  of  trucks  to  be  interdicted  in  zone  two 
are  selected  by  the  military  gamer.  The  number  is  usuatly  less  than  the 
number  of  trucks  interdicted  in  zone  one. 

i.  ATP  Arrival.  The  ATP  arrival  (ATPARV)  subroutine  (#6  in  figure  3) 
checks  the  ammunition  mix  number  of  the  arriving  truck  and  the  quantity  of 
rounds  needed.  It  then  checks  the  quantity  of  that  amnunition  on  hand 
against  the  total  demand  for  that  type  of  ammunition.  The  demand  is 
determined  by  checking  the  number  of  trucks  in  the  queue  waiting  for  that 
particular  type  of  ammunition.  If  there  is  sufficient  ammunition  and  if 
the  amnunition  type  is  one  of  artillery,  a  further  check  is  made  of  the 
total  artillery  demand  against  the  powder  on  hand.  If  there  is 
insufficient  amnunition  or  powder  to  provide  the  truck  with  a  load  once  it 
reaches  the  head  of  the  line,  it  is  sent  to  the  ASP.  Otherwise,  the  truck 
waits  to  be  served.  The  first  truck  to  arrive  generates  an  ATP  event, 
other  trucks  arriving  wait  for  the  next  available  server. 

j.  ATP  Event.  The  ATP  event  subroutine  (#7  in  figure  3)  simulates  the 
activities  that  take  place  at  the  ATP.  The  arrival  of  a  unit  truck 
triggers  the  first  ATP  event;  subsequent  ATP  events  are  scheduled 
automatically  at  the  end  of  the  reload  time  for  that  truck.  The  simulation 
begins  with  one  active  server  for  each  queue  (maneuver  and  artillery). 
Provisions  exist  for  an  idle  server  in  one  queue  to  assist  the  other,  and 
for  activating  an  additional  server  should  one  or  both  queues  become 
lengthy.  Initially,  the  ATP  subroutine  removes  a  unit  truck  from  a  queue, 
determines  the  desired  type  of  amnunition,  then  searches  the  queues  of 
replenishment  S&P  trucks  to  find  a  truck  with  the  right  ammunition  and  the 
least  amount.  A  match  having  been  found,  the  unit  truck  is  loaded,  and  the 
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S&P  trailer  load  is  decremented  by  the  number  of  rounds  removed.  If  the 
unit  truck  needed  artillery  ammunition  then  a  check  would  have  been  made  of 
the  amount  of  oowder  available.  After  the  project*' les  ar-e  loaded  the 
powder  truck  wou’d  be  decremented  the  same  number  of  rounds.  The  un*t 
truck  is  then  scheduled  for  a  unit  arrival  (UNTARV-  having  successfu" ly 
passed  OD9-at*onal  ava*'lap*"'ity  and  interdiction.  When  tne  S&P  trailers 
become  empty  they  are  sent  back  to  e*ther  the  CSA  or  ASP  depending  upon 
their  initial  origin.  Thus,  the  ATP  subroutine  schedules  arrivals  at  the 
CSA,  ASP,  or  unit,  and  reschedules  itself. 

k.  ASP  Arrival.  The  ASP  arrival  (ASPARV)  subroutine  (#8  in  figure  8) 
places  an  arriving  truck  into  one  of  two  queues,  the  GSRS  queue  or  the  "all 
other"  queue.  Since  the  GSRS  trucks  have  a  self-loading  capability  it  is 
assumed  that  they  can  load  themselves  at  the  ASP,  thereby  allowing  all  the 
servers  assigned  to  the  ASP  to  handle  other  resupply  requirements.  The 
arriving  truck  is  put  in  the  proper  queue.  As  servers  become  available 
trucks  are  removed  from  the  queue  by  the  ASP  event. 

l.  ASP  Event.  The  ASP  event  (ASP)  subroutine  removes  a  truck  from  the 
queue,  determines  the  type  of  anmunition  required,  calculates  the  load  time 
as  a  function  of  the  ammunition  type,  and  schedules  a  unit  arrival  for  the 
truck.  Again,  operational  failure  and  interdiction  are  checked  before  the 
unit  arrival  time  is  calculated.  As  long  as  there  are  idle  servers,  trucks 
are  removed  from  the  queue  for  servicing,  thus  simulating  concurrent 
service  of  as  many  trucks  as  there  are  servers.  Upon  reloading  a  truck  the 
current  stockage  is  updated.  Each  ASP  event  schedules  a  subsequent  ASP 
event  for  the  next  truck  in  the  queue. 

m.  CSA  Arrival  and  ASP  Arrival  1.  ARM  replenishes  ATP  stocks  from 
both  the  CSA  and  ASP  using  basically  the  same  methodology.  These 
subroutines  simulate  the  arrival  at  either  place  of  an  S&P  tractor,  either 
alone  or  with  an  empty  trailer,  and  the  subsequent  dropping  of  the  empty 
trailer  and  picking  up  of  a  full  trailer  load  of  anmunition.  It  is  assumed 
that  the  full  trailer  has  already  been  loaded  and  all  the  tractor  has  to  do 
is  take  on  some  fuel  and  hook  on  to  the  trailer.  Therefore,  a  short  reload 
time  is  used.  Both  subroutines  subsequently  schedule  the  arrival  of  this 
truck  at  the  proper  ATP,  having  checked  for  operational  failure  and 
interdiction.  The  rounds  removed  are  added  to  a  counter  of  total  rounds 
removed  from  both  the  CSA  and  ASP.  The  CSAARV  subroutine  can  also  schedule 
S&P  trucks  to  arrive  at  the  ASP  to  simulate  replenishment  of  the  ASP  stock. 

n.  ATP  arrival  1  and  ATP  Arrival  2.  These  two  subroutines  place  the 
S&P  trucks  in  two  separate  queues  at  the  ATP,  one  for  trucks  coming  from 
the  CSA  and  the  other  for  trucks  from  the  ASP.  It  also  updates  the  current 
supply  of  ammunition  at  the  ATP  and  changes  the  truck  status  to  being  in 
the  queue  at  the  ATP. 


o.  Helicopter  Arriva".  The  helicopter  arr’v a:  ."HELAR’/l  subroutine  ;s 
scheduled  ^rom  DEMAND  wnenever  the  sur-ent  suoD’y  of  HE  or  I  CM  arnmun^fion 
it  i  135rrm  artillery  battery  oeccmes  "ess  than  or  aqua’  to  the  cr-*  vca’ 
-esupo’y  "eve’.  J ELAR V  si-’u’atss  the  o-'ckuD  of  3  T*x§d  'cad  of  HE  and  \Z'A 
arnnun-fcn  at  the  AS?  oy  a  DHA7  ne';:cp:er  and  the  subsequent  :e';/ery  t: 
t-e  :es ■mated  batte'’"'.  's,J*er  the  ev°nt  actoa''^  takes  o' ace,  t“e  c'j''’*ent 
i-oo'y  of  eac.n  of  :.~e  ~-*c  amnurr*.  •'on  tyoes  at  t*e  oatte-y  ;s  „o:a:a:, 
snowing  tne  receipt  of  tne  ammunition.  It  also  oecremencs  t,*e  oumcer  ;* 
helicooters  serving  the  unit  and  schedules  the  helicooter's  arrival  back  at 
the  ASP. 


p.  Helicopter  ASP  Arrival.  This  subroutine  (HASPAR)  brings  the 
helicopter  back  to  the  ASP  and  updates  the  number  of  helicopters  available 
for  resupply  missions.  The  helicopters  are  subject  to  operational  failure 
in  the  same  manner  as  the  trucks,  but  are  not  interdicted. 

q.  Initialization.  Initialization  consists  of  those  actions  taken  by 
the  console  operator  to  out  ARM  into  operation.  A  detailed  descriptor  o * 
procedures  to  be  followed  can  be  found  in  Appendix  A,  ARM  Operators  3uide. 

6.  TYPES  OF  OUTPUT.  At  the  completion  of  a  specified  'period  of  simulated 
combat,  ARM  is  designed  to  provide  a  complete  status  report  on  the 
ammunition  resupply  network  of  the  division.  This  is  accomplished  by  means 
of  an  audit  trail  of  all  events  and  a  number  of  reports  generated  by  the 
subroutine  called  REPORTS.  From  the  REPORTS  subroutine  it  is  possible  to 
select  one  or  all  of  the  following  reports: 

1.  TRUCK  STATUS 

2.  UNIT  STATUS 

3.  SINGLE  ATP  REPORT 

4.  ASP  REPORT 

5.  CSA  REPORT 

6.  MULTIPLE  ATP  REPORT 

7.  AWO  REMOVED  FROM  ASP 

8.  TRUCKS  THAT  HAVE  SEEN  KILLED  OR  BROKEN 

a.  The  truck  report  provides  a  complete  status  of  each  truck.  It 
identifies  the  owning  unit,  specifies  its  location;  i.e.,  on  the  road  or  at 
the  unit,  identifies  the  type  of  ammunition  being  carried  and  percentage  of 
the  total  load  on  board,  and  specifies  the  next  time  the  truck  will  fail. 
The  truck  report  is  normally  printed  in  conjunction  with  the  unit  status 
reports.  A  sample  of  a  truck  status  report  is  shown  in  figure  9  along  with 
the  parent  unit. 

b.  The  unit  report  provides  the  current  status  of  each  unit, 
reflecting  unit  identification,  servicing  ATP  and  ASP,  and  the  respective 
distances  to  the  ATP  and  ASP.  Additionally,  it  identifies  each  ammunition 
type  used  by  the  unit.  For  each  type  it  specifies  the  associated  weapon. 
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Figure  9.  Unit  Status  Report 


the  number  of  surviving  weapons,  the  current  supply  of  ammunition  or  tne 
weapons,  number  of  -ounds  sho’-t,  percentage  of  basic  load  on  the  weapons, 
and  the  number  o~  rounds  o*  ammunition  on  the  trucks  located  at  the  unit. 

A"!  so  soec'*':ec  ■'or  each  anrnun-'f'on  type  '$  the  total  demand  ‘O'-  tne  oast 
oeriod  of  combat.  A  samp'. e  of  a  unit  report  ’ s  also  shown  in  -igure  9. 

c.  “he  sine's  AT*  reoo-t  oroviaes  information  on  eacn  AT*  suer  as 
number  of  servers  'forklifts!  active  in  eacn  oueue  and  tne  numper  of  trucks 
waiting  to  be  serviced.  It  also  specifies  for  each  ammunition  type  handled 
by  the  ATP,  the  current  demand,  the  amount  on  hand,  and  what  the  initial 
stockage  was.  A  sample  of  an  ATP  report  is  shown  in  figure  1C. 
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Figure  1C. 

ATP  Report. 

The -ASP"  report  specifies 

the  number  of  active 

servers  'forklifts 

and  cranes),  the  number  of  trucks  waiting  to  be  loaded,  and  the  current 
supply  of  each  type  of  anmunition. 

e.  The  CSA  report  only  registers  the  number  of  rounds  of  anmunition 
drawn  out  of  the  CSA  since  the  beginning  of  the  war  game. 

f.  The  multiple  ATP  report  and  the  report  on  ammunition  removed  from 
the  ASP  are  similiar  to  the  single  ATP  report  and  the  CSA  report. 


g.  The  last  report  {Type  8)  lists  each  truck  that  has  been  interdicted 
or  is  being  repaired.  The  report  identifies  the  owner  of  the  truck,  what 
type  it  is,  and  the  type  of  anmunition  it  was  carrying  {see  figure  11'. 


7.  XAR  GAME  INTERFACE. 


a.  arm  was  jes’ined  to  adant  to  "ea r'j  any  attr-'o'on  oased  war  game 

'of  any  3;zs  jo  to  jiv‘s4on' .  It  mere'/  -ecu'-es  tne  arnmun^t'cn  demand  ;n 
terms  of  '•ounds  ■'"ad  oy  type  ana  one  '’urroer  reason  systems  toat  ■'"ac. 
3:th  t"ase  /a’jes  must  os  fstn'totsd  amc^c  fa  .n'ts  os'"?  :2~ed.  r:" 

some  scleras,  ;t  may  be  oetoe"  to  oeve'oo  :"ese  semanos  oasao  .cor  s:-e 
particular  scenario,  tnen  :o  use  tnem  as  constant  -'"Puts  to  ARM,  performing 
variations  in,  for  example,  perhaps,  the  ‘HDE  truck  structure  or  method  of 
resupply.  It  is  important,  however,  to  illustrate  the  method  by  which  a 
typical  war  game  could  be  modified  to  produce  the  desired  information. 

This  paragraph  shows  the  specific  calculations  that  were  entered  into  the 
coding  of  the  JIFFY  war  game  (versions  I  and  II)  to  accommodate  the 
requirements  of  ARM. 

b.  JIFFY  is  a  computer  assisted  interactive  war  game,  which  takes 
manual  map-play  input,  compares  the  forces  that  opposing  force  gamers 
commit  against  each  other,  and  determines  attr't'on  of  weaoons  by  source, 
FE3A  movements,  and  expenditures  of  ammunition. 

(1)  The  overall  committed  31 ue  force,  whether  it  be  a  company  or  a 
corps  (or  anything  in  between),  is  divided  into  sectors  such  that  each 
sector  bounds  a  particular  confrontation.  Sectors  are  artificial 
boundaries  used  to  isolate  particular  portions  of  the  battle  that  possess  a 
certain  set  of  environmental  conditions.  Factors  used  to  define  a  sector 
are  unit  tactical  boundaries,  terrain,  defensive  or  offensive  tactic,  etc. 

(2)  Finally,  the  gamers  define  the  time  segments  they  wish  to  play. 
Each  segment  is  called  a  Critical  Incident  (Cl)  and  is  used  to  define  a 
particular  battle  or  confrontation  of  forces.  Usually,  gamers  select  CIs 
to  be  4  hours  (of  battle-time)  long.  A  night  Cl  may  last  6  or  3  hours. 

(3)  For  each  Critical  Incident,  each  sector  of  the  battle  is  played. 
Hence,  when  the  game  begins,  CI1,  sector  1  is  played;  then  CI1,  sector  2, 
etc.,  until  all  sectors  have  been  completed.  The  play  of  each  sector 
begins  as  the  opposing  gamers  input  a  series  of  "command  decisions,"  which 
further  define  the  tactics  and  environmental  conditions  of  the  sector. 

Once  these  values  have  been  entered  into  the  computer,  the  battle  within 
each  sector  is  determined  by  a  series  of  computer  subroutines,  which  focus 
on  a  particular  function.  For  example,  armor-antiarmor,  indirect  fire,  air 
defense-helicopter,  and  dismounted  infantry  are  some  of  the  functions 
played.  Essentially,  each  computer  subroutine  takes  the  environmental  and 
tactical  Input,  counts  the  number  of  Red  and  Blue  weapon  systems  involved 
in  the  specific  battle  function,  degrades  the  firepower  capability  of  those 
systems  accordingly,  and  computes  the  number  of  weapon  systems  on  each 
force  killed  and  the  number  of  rounds  fired  to  accomplish  those  kills.  All 
killer-victim  score  tables,  unit  equipment  strengths,  and  other  similar 
statistics  are  adjusted.  The  gamers  evaluate  these  statistics,  make 
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adjustments  to  their  forces  in  position  and  perhaps  tactics,  then  conmence 
with  the  next  Cl. 

'4'  “’-ODerly  assessing  the  amnun-'tion  '■esuDply  problem  -eaui-es  a 
knowledge  o *  the  number  of  weapons  that  actually  fire,  the  number  o*  those 
that  survive  (obviously  a  "ki’led"  weapon  ooes  not  need  to  oe  -esupo1 -ed' , 
and  the  number  of  rounds  '’red  by  those  survivors.  "Che  ’•emainder  o*  this 
paragraph  deals  with  the  specific  calculations  needed  within  JIFFY  to  feed 
ARM  its  demand  information. 

c.  Because  of  the  internal  logic  and  analysis  used  to  develop  the 
JIFFY  game,  it  was  necessary  to  categorize  two  different  type  of  weapon 
systems  for  the  demand  calculations. 

(1)  Category  A  type  weapons  are  defined  as  those  that  act  somewhat 
independently,  such  as  tanks,  TOWs,  DIVAD  guns,  etc.  These  weapons, 
although  part  of  a  precisely  defined  unit  (for  firepower  and  maneuver 
control),  will  engage  targets  individually.  Most  of  their  engagements  are 
determined  within  the  armor-antiarmor  routine  of  JIFFY,  enabling  the  demand 
calculation  to  be  performed  for  each  in  a  similar  fashion. 

(2)  Category  B  type  weapons  are  defined  as  those  that  fire  as  part  of 
a  group  of  weapons,  such  as  155mm  or  8  inch  artillery,  mortars,  and  GSRS. 
These  systems  are  handled  in  JIFFY  within  the  indirect  fire  routine  and  are 
treated  uniformly;  that  is,  if  the  gamer  has  committed  several  155mm 
artillery  batteries  into  one  sector,  and  during  a  particular  critical 
incident  he  decides  to  fire  his  155mm  artillery  in  that  sector  at  a  certain 
level  (rounds  per  hour  per  tube),  then  the  JIFFY  indirect  fire  subroutine 
will  force  each  tube  to  fire  at  the  same  rate  (with  the  same  kind  of 
ammunition) .  This  subsequently  makes  the  demand  calculation  for  ARM  simple 
because  each  weapon  system  of  Category  B  is  treated  identically  (within  a 
sector). 

(3)  Demand  calculations  for  Category  A  type  weapon  systems  are  handled 
as  follows.  „ 

(a)  Since  nearly  all  calculations  for  Category  A  weapons  are  performed 
within  the  JIFFY  Armor-Anti  armor  (AA)  subroutine,  it  is  important  to 
understand  one  major  portion  of  the  AA  logic.  Once  the  gamers  have  elected 
to  play  the  AA  routine  for  a  certain  sector,  they  must  begin  by  choosing  a 
range  that  will  separate  the  opposing  forces  when,  theoretically,  the  first 
hostile  rounds  are  fired.  Options  include  500-meter  gradations  from  500  to 
3500  meters.  After  this  selection  is  made,  the  gamers  each  input  the 
percent  of  the  maneuver  forces  located  in  the  sector  that  are  to  be 
involved  (percent  committed)  in  the  first  engagement.  The  computer  then 
assesses  the  firers,  rounds  fired,  and  losses  to  both  sides.  After  this 
assessment,  the  gamers  appraise  the  results  and  select  the  next  engagement 
range,  and  the  next  cycle  is  performed  similarly.  For  example,  the  gamers 
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■nay  select  'our  successive  ranges:  25COm,  200Cm,  15COm,  ISOCm,  wnich 
suggests  that  the  attacking  *orce  began  to  exchange  rjre  at  2500  meters, 
closed  to  13 CO  meters,  and  after  a  'engthy  gnt"  at  the  c’oser  -ange, 

broke  contact  to  ’•egrouo. 


'  S  ^  rO’JdhC’J  Z3l  *  C  'J  *  1 1  “* S  "’nC8 

se'ectec  ;s  •'efer^ec  to  as  a  '3;tuac;  ;n.  1  I-1  t-'e  aocve  exa.mo’e,  t 

■*our  situations  In  *hic.n  flrers,  targets,  kills,  and  'ounos  *-'-eo 

assessed.  The  following  terms  are  defined: 


are 


:  r*  3 


S  *  number  of  battle  situations  played  in  JIFFY. 


NW-jj  a  the  total  number  of  Blue  weapons  of  type  i  In  the  force 
array  (by  sector)  at  the  beginning  of  situation  j. 

LOSS-} j  a  the  total  number  of  Blue  weapons  of  type  1  killed  by  the 
Red  force  during  situation  j. 

NSURV}j  a  the  total  number  of  Blue  weapons  of  type  i  that  survived 
situation  j. 

NSURVij  3  MW i j  -  LOSS i j 

RNO}  a  total  number  of  rounds  fired  by  Blue  weapons  i  during  the 
entire  Cl  (at  all  targets). 

Other  factors  particular  to  weapons  and  taken  directly  from  the  JIFFY 
methodology  are: 

OA}  a  operational  availability  of  Blue  weapon  i 
SF}  a  suppression  of  Blue  weapon  i 

ECF}  a  expected  number  of  completed  firings  for  each  Blue  weapon  1 
Some  general  scenario  factors  (not  weapon  dependent)  are: 

PCOMj  a  percent  of  Blue  force  committed  during  situation  j 

SMKj  a  degradation  of  Blue  force  due  to  smoke  during  situation  j 

(c)  The  Initial  thrust  must  be  to  determine  two  important 
probabilities:  the  probability  that  a  weapon  fires  (prob(FIRE< j))  during 
a  particular  situation,  and  the  probability  that  a  weapon  survives  a 
particular  Cl  (prob  (SURV})).  The  number  of  flrers  (by  type  weapon  i)  in 
a  particular  situation  j  can  be  calculated  as: 

WFij  ,  NW} j  *  OA ■}  *  SF i  *  PCOMj  *  SMKj  (2) 
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Assuming  a  Bernoulli  situation,  then,  a  SDecific  weapon  can  have  two 
conditions:  either  it  is  a  firer  or  it  is  not.  Hence,  the  probability 
that  a  weapon  fires,  taken  rrom  the  sample  data,  is  the  -e lationship  of  the 
number  of  f->ers  to  the  numbe*  of  systems  'of  type  i)  that  could  *ire  'or 
the  number  of  weapon  systems  committed  'in  situation  j)). 

Fi-st,  the  number  of  systems  connrttec  is  portrayed  by  equation  '3'. 

NCOMij  r  NW -j j  *  PCOMj  (3) 

The  probability  during  situation  j  that  any  weapon  would  fire  (of  those 
comnitted)  is: 

^ij  (4) 

Prob  (FIREfJ)  *  nOTJJ 


This,  of  course,  must  be  multiplied 
circumstance  would  happen,  which  is 
would  be. in  the  committed  force,  or 
NCO^i i/NWij  and  prob  (Commitment)  * 
prob  (FIRt*jj)  to  obtain  the  overall 


by  the  probability  that  this 
simply  the  probability  that  the  weapon 
present  committed.  Since  PCOM^-  * 
PCOM,  this  factor  is  multiplied  by 
(total)  probability  of  fire: 


Prob  (TFIREij)  »  NWF  ^ 


NW  • 


ij 


(5) 


Equations  (2)  and  (3)  are  then  substituted  into  equation  (5): 


Prob  (TFIRE  ) 

-  ~  1J 


NCOM  *  OA  *  SF  *  SMK 

_ V  1  1  J 

NW 

ij 


(6) 
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;inally,  tne  probability  that  a  particular  *eaDon  “'res  Pur 'og  the  snt’>e 
2!  is  determined  by  combin'ng  the  orobaDi 1 ities  *cr  each  individual 
situation.  "or  each  situation,  the  probability  that  a  weapon  *'s  not  a 


3'cb  N  -'RE,,.'  =  l-3-ob  ""IRE.,- 


Then,  assuming  independence  of  situations,  the  probability  a  weapon  did 
not  fire  throughout  the  Cl  is  the  product  of  the  above  individual 
probabilities: 


S 

Prob  (NTFIRE:)  =  7T  l-prob(TF!R£. .)  '3) 


Then,  the  probability  that  a  weapon  fired  during  the  entire  Cl  can  be 
expressed  as  shown  in  equation  (9)  below: 


Prob  (TFIREi)  *  1-prob  (NTFIRE.)  (9) 


(d)  The  probability  of  survival,  however,  need  not  be  determined  by 
situation.  It  may  be  calculated  with  data  that  pertains  to  the  entire 
Cl.  Prob  (SURVi)  defined  as  the  probability  that  weapon  i  will 
survive  a  given  Cl.  Then: 


Prob  (SURV.)  -  NWn  -  JET  KILL,  (10) 

8  TOT  1 

^13 

where  B  indicates  the  beginning  of  the  Cl. 


This  procedure  will  permit  the  probability  of  survival  to  account  for 
kills  by  all  sources  as  well  as  the  armor-antiarmor  assessment. 

(e)  To  calculate  the  probability  that  a  particular  weapon  ’'s  a 
"firing  survivor"  (i.e.,  the  weapon  remain  alive  at  the  end  of  the  Cl  and 
had  expended  rounds),  one  further  assumption  is  made: 
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that  the  events  of  firing  and  surviving  are  independent.  This  is  not  a 
fa'r  assumption,  since  the  act  of  *iring  creates  a  51 i ng  signature,  wnich 
deceases  the  firer's  chance  of  surviva’.  However,  considering  the 
■"^solution  o’ayed  ’n  J I F Fv  and  the  ract  that  detemrn’ng  the  necessary 
correlation  coefficients  <s  nearly  impossible  with  the  data  ava-ab’e, 
this  assumption  o*  'noeoendencs  's  maoe  to  octain  a  *'gure  as  realistic  as 
Dossible  within  the  data  constraints.  Therefore,  tne  probability  that  a 
weapon  is  a  firing  survivor  is  calculated  with  equation  (11)  below: 

Prob  (FS-j )  =  Prob  (TFIRE, )  *  Prob  (SURVi).  (11) 

Similarly,  after  determining  the  probability  that  a  weapon  is  killed 
during  the  Cl  (Prob  (KILU)  as  l-P(SURVi),  the  probability  that  a 
weapon  i  fired  _and  was  killed  is  given  by: 

Prob  (FK-f )  =  Prob  (TFIREi )  *  Prob  (KILL,)  (12) 

This  equation,  along  with  equation  (11),  will  be  used  later  to  determine 
the  number  of  rounds  expended  by  the  survivors  and  those  killed. 

(f)  The  final  step,  then,  is  to  calculate  the  expected  number  of 
firing  survivors.  Since  this  circumstance  can  be  described  by  the 
binomial  family,  the  expected  value  can  be  expressed  by  the  number  of 
elements  subject  to  the  probability  times  the  probability  itself,  or 


E  (FS-j )  =  Prob  (FSt)  *  (13) 

(g)  By  sector,  JIFFY  produces  the  total  number  of  rounds  fired  by 
type  weapon  during  the  entire  Cl.  However,  it  does  not  break  this  number 
down  into  those  fired  by  the  surviving  weapons  and  those  fired  by  the 
weapons  that  were  killed.  Taking  the  total  number  of  rounds  fired  by  type 
calculated  within  JIFFY,  and  sunning  for  all  situations,  RND-,-  is  defined 
as  the  total  number  of  rounds  fired  during  the  Cl  by  weapon  i.  Since 
E(FS-j)  and  E  (FK-j),  the  data  calculated  similarly  to  equation  (13), 
combine  to  fire  the  entire  number,  and  assuming  that  kills  occur  uniformly 
throughout  the  Cl,  the  number  fired  by  the  survivors  can  be  obtained  as  a 

simple  ratio.  Let  RFS-j  be  the  number  of  rounds  fired  by  the  firing 

survivors,  and  let  RFW-j  be  the  number  of  rounds  fired  by  each  weapon  of 

type  i.  Then: 


RFW. 


RNOj 


■SHFty 


W,) 

— T — 


(14) 
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-fence:  RFS<  =  E  'FS,)  *  RFW.  '15.' 


'V  or  Category  A  jn'ts,  tie  oi '  owog  ; a 1  cu ^  atons  ’’use  :e 
ccmo'eted: 

1.  Ecuador  1"  -use  :a  la'cj'acec  •*:’*  -rac-1  cyce  *eaoc"  -  ea;-  o  ■  c 
.t: '  oog  equators  apoearog  o  t.te  :e-/e'  cement' . 

2.  The  results  of  equation  (13)  must  be  apportioned  to  each  Category 
A  unit  in  the  sector  in  direct  proportion  to  the  density  of  weapons  of 
that  type  in  each  unit  and  its  combat  intensity  level. 

Once  the  number  of  firing  survivors  has  been  apportioned,  the 
number  of  rounds  expended  must  be  calculated  using  equations  (13)  and  (14). 

(4)  Demand  calculations  for  Category  3  type  weapon  systems  are 
developed  as  follows: 

(a)  Category  3  units,  as  defined  -n  oaragraph  7C,  possess  a  much 
simpler  solution  concerning  the  demand  data  preparation^-  Category  A  units 
(particularly  because  of  the  Jiffy  methodology  for  determining  firers, 
etc.)  required  calculation  on  the  actual  number  of  weapon  systems  that 
expended  rounds.  In  the  case  of,  say,  an  artillery  battery,  resupply  is 
done  at  the  battery  level  to  all  firing  weapons  simultaneously  (or 
continuously  as  would  be  the  real-world  case).  Jiffy  methodology, 
however,  fires  all  weapons  within  an  artillery  battalion  equally. 

Although  operational  availability,  smoke  or  EW,  and  comnander ' s  percent 
employment  may  restrict  the  guns  from  firing  continuously,  when  one  fires, 
they  ^1_[  fire. 

1,.  The  following  terms  are  defined: 

Ni  »  number  of  weapons  of  type  i  in  the  force  (by  sector)  at  the 
beginning  of  the  Cl. 

TBATi  a  number  of  tubes  of  weapon  type  i  in  each  battery 

KILL -f  »  number  of  tubes  of  weapon  type  i  killed  in  each  battery 

RND^j  3  number  of  rounds  of  type  j  fired  by  weapon  type  i  during 

the  Cl . 

2.  With  Category  B  weapons,  the  assumption  is  made  that  if  any  firing 
was  "cfone  during  the  Cl  by  weapon  type  i,  the  probability  that  any  single 
weapon  of  that  type  fired  is  1.  Hence,  the  only  concern  is  with  the 
probability  of  survival  which,  as  before,  is  the  relationship  of  those  of 
weapon  i  that  survive  a  given  Cl  to  the  total  of  those  that  started  the 
Cl.  Since  ARM  bases  its  resupply  cycle  on  demand  (as  opposed  to  resupply 
to  a  basic  load),  the  only  purpose  ’n  carrying  the  weapon  survival  status 
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for  artillery  s s  simply  to  adjust  the  numbe1"  of  '■ounds  expenaed. 

Similarly,  as  with  Category  A  urr' ts,  the  number  of  rounds  'i-ed  by  weapons 
that  survive  a  particular  Cl  must  be  dete-mined  s'nce  "dead"  weapons  wi’l 
not  be  resupplied.  Hence,  let  RFSi,:  =  the  number  -of  rounds  of  type  ; 

•cired  by  survl vi nq  weapons  of  i  ,  v  ana  let  RF'w^  oe  the  numoe’- 

of  rounds  ‘i-ed  by  each  weapon  or  -ounc  type  j,  then:  J 


and,  therefore:  RFS..  =  RFW..  *  (N.  -  KILL.)  (171 

ij  ij  :  r 

Since  JIFFY  plays  artillery  by  battery,  and  ARM  likewise  plays  resupply  at 
battery  level,  the  data  requirements  are  consistent. 

(b)  For  Category  B  units,  the  following  calculations  must  be 
completed. 

1.  The  number  of  surviving  weapons  of  type  i  for  each  battery  of 
artillery  (per  sector).  This  result  was  already  produced  by  the  existing 
JIFFY  methodology,  so  no  alteration  was  required. 

2.  The  rounds  expended  by  weapon  type  i  of  anmunition  type  j  (per 
sector).  For  simplicity  purposes,  since  the  data  in  (1)  above  and 
provided  by  sector,  the  ammunition  consumption  can  be  presented  as  a 
sector,  expenditure. 

d.  This  subparagraph  describes  the  format  in  which  the  demand  data 
must  be  presented  to  be  compatible  with  ARM.  Figure  2  below  is  a  sample 
data  printout,. _which  illustrates  the  form  and  substance  of  the  demand 
information.-  In  this  case,  the  data  originate  within  the.  JIFFY  FORTRAN 
coding  in  the  manner  previously  described  and  and  stored  in  an  array. 

When  printed,  the  data  appear  in  the  format  shown  in  figure  12,  and  ARM 
reads  the  data  sequentially  using  the  same  format  shown. 
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a. 

~  # 

d. 

e. 

c 

T1A 

0.000 

1.000 

29.100 

13.439 

29. 712 

3.JGC 

D.DCO 

2.900 

1 . 382 

:cc 

25 .  DOC 

*  i 

-  V  .  -vO 

2  .  0  0^ 

2.  DS9 

D.DCO 

: i.Dco 

D.DCO 

D.DCO 

94.514 

1:. DCC 

•>  ■'rc1 

'  n 

3I2FA 

0.000 

4.000 

5.000 

6.000 

303.121 

0.000 

5.000 

5.000 

5.000 

13.988 

0.000 

5.000 

6.000 

6.000 

515.423 

0.000 

0.000 

0.000 

0.000 

0.000 

0.000 

0.000 

0.000 

0.000 

0.000 

1ACAS 

4.000 

13.000 

3.537 

3.537 

16.473 

4.000 

13.000 

3.814 

3.314 

14.748 

4.000 

13.000 

3.737 

3.737 

19.255 

4.000 

13.000 

3.414 

3.414 

13.179 

0.000 

0.000 

0.000 

0.000 

0.000 

Figure  12.  Jiffy  Demand  Data 
A  description  of  each  column  of  figure  12  follows: 

(1)  Column  a,  the  unit  name.  This  name  corresponds  directly  in 
spelling  to  the  unit  name  known  to  JIFFY  (loaded  by  the  gamers).  It  must 
also  correspond  to  the  unit  name  internal  to  ARM. 

(2)  Column  b,  number  of  surviving  helicopter  sorties  (number  of 
surviving  helicopters  times  number  of  sorties  each).  JIFFY  calculates  the 
number  of  TOW  (or  similar  missile)  firings  based  upon  the  number  of 
helicopter  sorties  flown,  consequently,  ARM  has  been  programmed 
similarly.  Essentially,  JIFFY  assumes  that  a  helicopter  will  fire  all  of 
its  rounds  before  returning  from  a  sortie.  If  the  helicopter  survives  a 
sortie,  it  must  be  reloaded.  This  logic  does  not  fit  directly  to  Category 
A  or  B  weapons,  so  it  is  treated  separately. 

(3)  Column  c,  ammunition  code  number.  This  code  corresponds  to  the 
ARM  anrno  codes  listed  in  Chapter  IV,  paragraph  3. 

(4)  Column  d,  number  of  weapons  in  this  unit  alive  (which  fire  the 
anmunition  indicated)  at  the  end  of  the  Cl. 
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(5)  Column  e,  number  of  firing  survirors  of  the  weapon  indicated  in 
column  d.  This  number  indicates,  of  those  weapons  that  survive  the  Cl 

{ column  dl,  the  number  that  expended  ammunition. 

(6)  Column  f,  rounds  fired.  This  column  displays  the  total  number  of 
rounds  ri*"9d  by  tne  firing  survivors  'this  number  is  most  like’y  less  than 
tne  total  -ounds  *ired  in  JIcrY  because  some  rounds  were  probably  expended 
by  killed  weapons). 

e.  The  assumptions  and  equations  described  in  this  paragraph  are 
presented  to  illustrate  a  technique  that  can  be  used  to  adjust  any 
attrition-based  war  game  to  produce  demands  for  ARM.  Although  JIFFY  logic 
allowed  a  somewhat  straightforward  development,  some  models  may  require  a 
more  detailed  series  of  calculations,  while  some  may  require  none  at  all. 
And,  as  explained  earlier,  ARM  may  be  used  in  a  stand-alone  fashion 
without  an  adjoining  war  game.  In  that  case,  the  demands  could  be 
manufactured  in  a  format  similar  to  that  of  figure  12,  and  these  values 
could  be  read  directly  into  ARM,  thereby  permitting  the  analyst  to 
manipulate  the  demand  levels  as  he  desires. 
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APPENDIX  A 


ARM  Operators  Guide 

A-l.  DURPOSE.  The  Allowing  is  a  set  of  procedures  to  enable  use  of  the 
Ammunition  ResuPDly  Mode1  'ARM).  The  procedures  assume  that  the  operator  *‘s 
logged  in  on  a  CRT  type  terminal  with  a  150K  octal  password.  Attach  the 
required  *iles  for  ARM  to  execute. 

ATT ACH , T1 , HD ARMDAT A , I D *TRAC0MD  (beginning  data  file) 

ATTACH,T2,HDARMEVENT$,ID*TRAC0MD  (empty  event  file) 

ATTACH, T3,  (local  file  name),  ID  =  (permanent  file  name)  (JIFFY  created 
input  file) 

The  next  statement  accesses  a  call  file,  which  has  the  job  control  statements 
required  to  process  the  ARM. 

CALL,HJARMANOTHER,ID*TRACOMD 

A-2.  METHODOLOGY.  During  the  processing  of  the  ARM,  a  number  of  messages 
will  be  written  to  the  CRT  that  provide  information  and/or  require  operator 
response.  These  messages  will  be  referred  to  herein  as  CUES.  The  operator 
response,  if  required,  will  be  referred  to  herein  as  ANS,  with  RES  being  the 
result  of  the  operator  reply. 

a.  CUE:  RETAIN  EVENTS  CURRENTLY  SCHEDULED  (YES/NO) 

ANS:  N  or  NO 

RES:  Zeros  out  event  list 

b.  CUE:  ARE  YOU  CREATING  AN  ANSWER  FILE  (Y  or  N) 

ANS:  Y  or  YES  ~ 

RES:  Will  bypass  METRO  produced  input  file  to  enable  data  base  building  and 
the  creation  of  future  events,  goes  to  e  below. 

ANS:  N  or  NO 

RES:  Regular  logic  will  be  followed. 

c.  CUE:  ENTER  TIME  TO 


STOP  SIMULATION 


'»T' 


unt'  "  t'me  eoua's 


ANS:  240.1 


RES:  The  ARM  will  orocass  the  cri 
240.1  T'nutas. 


cal  'incident 


yj E:  initialize  'rucks1  'i^e  since  .as'  -aiiure?  'ves'nc' 


ANS:  /ES  or  i 

RES:  Trucks  are  loaded  with  time  since  last  failure  occurred  by  use  of 
a  uniform  random  number  between  0.0  and  1.0  multiplied  by  the  mean 
time  between  failure  (MT3F)  for  each  different  type  of  truck. 

e.  CUE:  (Known  as  the  control  menu.) 

(1)  -  EDIT  DATA 

(2)  -  WRITE  REPORT 

(3)  -  SCHEDULE  CONTROL 

(4)  -  RETURN 

(5)  -  STOP  SIMULATION  NOW 

(6)  -  EDIT  TRUCK  QUEUES 

(7)  -  CREATE  EVENTS 

f.  ALTERNATIVE  1 
ANS:  1 

RES:  Gives  control  to  the  edit  subroutine,  which  enables  modification 
and/or  listing  of  common  based  data.  See  annex  I  for. details. 

For  the  first  Cl  enter  variable  name  L’JOUT. 

CUE:  VARIABLE  NAME. 

ANS:  LUOUT 

CUE:  .  . 

ANS:  C  1  6.  This  transfers  the  output  to  tape  S,  the  output  tape, 
required  only  at  the  beginning  of  the  game. 

CUE:  .  . 

ANS:  Look 
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ANS:  C  1  1  —  Required  each  time  a  new  start  is  made  as  it  ^everts  back  to 
0  when  the  simulation  terminates. 

ANS:  INTER 

ANS:  12(1  Numoer  of  trucks  to  be  interdicted. 

ANS:  C  7  (  )  The  integer  to  be  used  as  the  cycle  number;  e.g.,  22  means 
that  every  22d  truck  to  move  in  the  simulation  will  be 
interdicted. 

CUE:  .  . 

ANS:  END 

RES:  Returns  to  control  menu,  e  above. 

Since  an  answer  file  or  history  file  is  being  developed  the  next  action  is 
to  create  the  events  that  will  force  feed  the  ATPs  with  additional 
ammunition.  This  involves  scheduling  the  arrival  of  S4P  trucks  at  the  ASP 
and  CSA  to  pick  up  new  loads  of  ammunition  for  delivery  to  the  ATPs. 

ANS:  7 

CUE:  TO  CREATE  AN  EVENT,  INPUT  AS  A  GROUP  SEPARATED  BY  COMMAS  OR  SPACES 
THE  FOLLOWING  7  Values:  EVENT  TYPE  (INTEGER  VALUES  BETWEEN  1  AND  17)  5 
PARAMETERS  FOR  EACH  EVENT  (INTEGER,  DEPEND  ON  EVENT  TYPE)  AND  TIME  (DECIMAL 
MINUTES,  REAL)  EXAMPLE:  9,  1,  508,  1,  0,  65.  CSA-TO-ATP  TRUCK  508  WILL 
ARRIVE  AT  CSA  AT  TIME  *  65  MIN. 

EXPLANATION  OF  9,  1,  508,  1,  0,  65. 

9  *  EVENT  TYPE  9,  ARRIVAL  OF  CSA  TRUCK  AT  CSA 
1  *  ATP  NO.  TO  WHICH  TRUCK  IS  GOING 
508  -  TRUCK  NO. 

1  *  ASP  NO, 

0  *  ZERO,  no  value,  but  required. 

65.  *  Time  in  minutes  when  event  is  to  occur.  The  decimal  point  is 
required. 

ANS:  9,  1,  508,  1,  0,  65. 

CUE:  ? 

ANS:  12,  1,  512,  1,  0,  45. 

CUE:  ? 

ANS:  END  -  after  last  event  has  been  scheduled 
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RES:  Returns  to  control  menu,  a  above.  If  creation  of  the  answers  fi’e  ,-s 
complete,  then  it  is  necessary  to  save  the  new  events  and  new  data  base. 
Therefore,  it  is  necessary  to  stoo  the  simulation  without  o^oceed'ng  jny 
•urtner. 

INS:  : 

RES:  Sc.neduies  a  stop  simulation  event  at  the  present  vme. 

CUE:  Stop 
CUE:  COMMAND 

RES:  Processing  is  complete,  new  files  available  are: 

LOCAL  FILE  NUMBER  Definition 

T1  New  data  base 

T2  New  events  file  containing  the 

events  just  created. 

An  option  available  at  this  time  is  the  cataloging  of  T1‘  and  72  to  form  the 
answer  files,  the  basis  for  a  restart  at  present  time  without  going  through 
the  time  consuming  process  of  creating  the  events  again.  Once  the  files 
have  been  cataloged  the  input  data  must  be  reconnected. 

ATTACH,  T3,  (local  file  name),  ID  *  (  )  — 

JIFFY  created  input  file. 

CALL,  HJARMANOTHER,  ID  »  TRACOMD 

CUE:  RETAIN  EVENTS  CURRENTLY  SCHEDULED  (YES/NO) 

ANS:  YES  of  Y 

RES:  Retains  events  currently  scheduled.  Return  to  paragraph  A-2,  b  for 
continuation  of  the; ARM  logic. 

g.  ALTERNATIVE; 2 
ANS:  2 

RES:  Gives  control’ to  report  subroutine.  Details  at  Annex  II. 

h.  ALTERNATIVE  3 


ANS:  3 

RES:  Prints  the  following  CUE 
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CUE:  ENTER  TIME  OF  NEXT  CONTROL  EVENT 
ANS:  240.05 

RES:  At  time  240.05  minutes  ARM  will  return  to  the  control  routine. 

1.  ALTERNATIVE  4 
ANS:  4 

RES:  Returns  to  main  driver  routines  to  continue  processing. 

j.  ALTERNATIVE  5 
ANS:  5 

RES:  Schedules  a  stop  simulation  event  with  the  present  time. 

k.  ALTERNATIVE  6 
ANS:  6 

RES:  Gives  control  to  subroutine  TRKPUT,  which  enables  modification  of 
truck  queue  assignments.  Examples  are  at  Annex  III. 

l.  ALTERNATIVE  7 
ANS:  7 

RES:  Gives  control  to  subroutine  CREEVT,  which  enables  the  creation  of  any 
type  event  for  later  processing.  See  Annex  IV. 

Normally  after  exercising  one  or  more  of  the  alternatives,  alternative  4  is 
chosen  to  start  the  processing  of  the  ARM. 

CUE:  HAVE 'FINISHED  RDJIFF 

ANS:  N/A  (information  only  that  the  input  tape  from  the  attrition  model 
has  been  processed). 

♦NOTE  1 

CUE:  SCHEDULED  STOP  TIME  *  240.1. 

♦NOTE  1.  If  a  control  event  had  been  scheduled  at  TIME  *  240.05  the 
menu  would  be  printed  here  enabling  the  printing  of  reports 
at  the  end  of  the  Cl. 


ANS :  N/ A  'information  only.  Accessing  of  Cl  is  complete).  -^les 
3va',ab',e  at  this  time  are  as  *ollows: 

-oca"  r ’  ■  a  Number  Cef^n^f' on 

"  *T  Data  :ase  -esult'ng  -”om  -on  just  como'e'-ec 

Events  c  r  a  c  are  to  a  a  o^ccessec  sc  a  : : -g 
suosequent  zo  240.1  oinuces 

Output  Audit  trail  of  all  events  and  listing  of  all 

reports 

An  option  available  at  this  time  is  the  cataloging  of  T1  and  T2  to  form  the 
basis  of  a  checkpoint  restart  at  battle  time  240.1  minutes.  However,  first 
the  output  should  be  batched  to  the  printer  to  obtain  a  status  of  the  units 
and  the  arauunition  resupply  network.  3efore  cataloging  T1  it  is  advisable 
to  call  HJEDIT  in  order  to  update  the  location  of  all  the  units  that 
participated  in  the  last  battle.  Since  the  3!ue  forces  are  giv-'ng  ground 
and  moving  back,  their  distance  to  the  AT?  and  ASP  will  become  shorter. 
Therefore,  it  is  necessary  to  change  the  distance  to  the  AT?  and  ASP  at  the 
end  of  each  Cl.  This  is  accomplished  by  subtracting  a  standard  distance 
from  the  values  contained  in  attributes  4  and  5  of  each  unit.  The  distance 
moved  by  artillery  batteries  will  probably  be  greater  than  the  distance 
moved  by  maneuver  battalions,  therefore,  each  unit  must  be  called 
separately.  To  accomplish  these  changes  the  following  procedures  should  be 
followed: 

CALL,  H JED IT,  ID  *  TRACOMO 
CUE:  EDIT  DATA  FILE?  (YES/NO) 

ANS:  N 

CUE:  UPOATE  ARRAYS? 

ANS:  Y 

CUE:  VARIABLE  NAME  (OR  END) 

ANS:  IUNIT 

CUE:  CHANGE  OR  REPLACE? 

ANS:  C 

CUE:  Enter  Word  #,  Attribute  #,  New  Value  (or  change) 

(0,  0,  0  When  Done) 
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ANS:  1,  4,  -4  (subtracts  4  km  from  ATP  distance  for  maneuver  unit  1) 
CUE:  NEXT- 

ANS:  1,  5,  -4  (subtracts  4  km  f’-om  ASP  distance  for  maneuver  unit  1) 
CUE:  NEXT- 


CUE:  NEXT- 

ANS:  19,  4,-6  (subtracts  6  km  from  ATP  distance  for  unit  19,  a  155mm 
battery) 


CUE:  NEXT- 

ANS:  19,  5,  -6  (subtracts  6  km  from  ASP  distance  for  unit  19,  a  155mm 
battery) 

CUE:  NEXT- 

ANS:  30,  5,  -5  (subtracts  5  km  from  ASP  distance  for  unit  30,  an  8  in 
battery) 

CUE:  NEXT- 

ANS:  0,  0,  0  (To  get  out  of  routine) 

CUE:  VARIABLE  NAME  (OR  END) 

ANS:  END 

CUE:  EDIT  DATA  FILE?  (YES/NO) 

Since  the  file  contains  the  results  of  the  first  Cl,  it  may  be  desirable  to 
simulate  previous  stockpiling  of  artillery  ammunition  at  the  first  and 
second  supplemental  positions.  To  accomplish  this  simulation  it  is 
necessary  to  have  the  output  from  the  Cl  available  to  find  out  which  units 
are  short  ammunition.  If  the  output  is  not  available,  the  information  can 
be  obtained  through  the  CRT.  The  method  of  providing  this  additional 
anmunition  is  to  update  the  current  supply  of  each  type  of  ammunition  to 
100  percent  of  the  basic  load  of  the  surviving  weapons.  To  accomplish  this 
the  following  procedures  should  be  used,  assuming  the  output  is  available 
to  look  at: 


ANS: 

YES 

CUE: 

VARIABLE 

NAME  = 

ANS: 

I'JNIT  19 

ww  i ; 

.  * 

ANS: 

C  10  0 

(Zeros  out  number  of  weapons  short  first  arrmunition 

type) 

CUE: 

•  • 

ANS: 

C  11  0 

(Zeros  out  number  of  rounds  short) 

CUE: 

•  • 

ANS: 

C  12  273 

(8rings  weapons  up  to  100  percent  of  basic  load  of 
ammunition  type) 

first 

CUE: 

•  • 

ANS: 

C  22  0 

(Zeros  out  number  of  weapons  short  second  arrmunition  type) 

CUE: 

«  • 

ANS: 

C  23  0 

(Zeros  out  number  of  rounds  short) 

CUE: 

•  • 

ANS: 

C  24  609 

(Brings  weapons  up  to  100  percent  of  basic  load  of 
ammunition  type) 

second 

This 

procedure 

is  continued  for  all  units  that  are  short  arrmunition 

.  Once 

completed  the  word  "END"  Is  entered. 
CUE:  .  . 

ANS:  ENO 

CUE:  EDIT  DATA  FILE?  (YES/NO) 

ANS:  N 

CUE:  UPDATE  ARRAYS 

ANS:  N 

CUE:  COMMAND 
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There  is  now  an  updated  data  file  on  TAPE  1.  Now  is  the  time  to  catalog 
TAPE  1  and  discard  or  return  Tl.  It  is  then  necessary  to  copy  TAPE  1  to  T 
before  processing  an  additional  Cl. 

Now  if  the  output  *rom  the  fi”*st  Cl  is  not  available  a  more  time  consuming 
process  ’s  followed  to  bring  the  un-its  up  to  100  percent  of  their  basic 
load. 

CUE:  EDIT  DATA  FILE?  (YES/NO) 

ANS:  Y 

CUE:  VARIABLE  NAME 
ANS:  IUNIT  20 
CUE:  .  . 

ANS:  L  10  12  (It  is  necessary  to  list  the  three  attributes  for  each 
ammunition  type  for  each  unit  in  order  to  determine  if  the  unit  is  short 
that  type  of  amnunition) 


CUE: 

IUNIT  20 

ATTRIBUTE 

10  =  7 

ATTRIBUTE 

11  *  140 

ATTRIBUTE 

12  *  133 

ANS: 

C  10  0 

ANS: 

C  11  0 

ANS: 

C  12.273- 

CUE: 

•  • 

ANS: 

L  22  24 

CUE: 

IUNIT  20 

ATTRIBUTE 

22  «  7 

ATTRIBUTE 

23  «  280 

ATTRIBUTE  24  *  329 


ANS:  3  22  0 


ANS:  C  23  3 

-NS:  3  2 A  5C9 

a***  "*v/a  3^07  -C  ,  Ar*:v  a  vCr^  *  I'lC* 

CUE:  .  . 

ANS:  END 

Now  by  answering  N  or  NO  to  the  next  two  cues  the  model  will  produce  the 
new  Tape  1,  which  should  then  be  cataloged  and  copied  to  a  new  Tl.  To 
process  an  additional  or  the  next  Cl  requires  only  the  following  two 
statements  to  be  keyed  in. 

ATTACH, T3,  (next  JIFFY  produced  file) 

CALL .HJARMANOTHER , ID=TRACOMD 

CUE:  DETAIN  EVENTS  CURRENTLY  SCHEDULED  (YES/NO) 

ANS:  Y  or  YES 

RES:  Events  created  last  Cl  which  are  part  of  local  file  T2  will  be 
retained. 

CUE:  Are  you  creating  an  answer  file  (Y  or  N) 

ANS:  N  or  NO 

CUE:  ENTER  TIME  TO  STOP  SIMULATION 
ANS:  480.1 

RES:  A  stop  simulation  event  is  scheduled  for  480.1  minutes. 

CUE:  INITIALIZE  TRUCKS,  ETC 
ANS:  N  or  NO 
RES:  NO  CHANGE 
QUE:  (1)  -  EDIT  DATA 

(2)  -  WRITE  REPORT 

(3)  -  SCHEDULE  CONTROL 
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(4)  -  RETURN 

(5)  -  STOP  SIMULATION 

(6)  -  EDIT  TRUCK  QUEUES 

(7)  -  CREATE  EVENTS 
ANS:  1 

CUE:  Variable  Name  * 

ANS:  LOOK  —  must  be  changed  each  time  the  program  is  started.  Only  way  of 
obtaining  a  complete  audit  trail. 

CUE:  .  . 

ANS:  C  1  1 
ANS:  TCI  ST 
CUE:  .. 

ANS:  C  1  240. 

RES:  Have  loaded  Cl  START  TIME  of  240  minutes 
CUE:  .. 

ANS:  INTER 
CUE:  .. 

ANS:  CIO—  Zeros  out  counter  for  zone  1  trucks 
ANS:  C  2  0  —  Zeros  out  counter  for  zone  2  trucks 
ANS:  C  3  Number  of  trucks  to  be  interdicted 

ANS:  C7  The  integer  to  be  used  as  the  cycle  number;  e.g.,  22  means  that 

every  22d  truck  to  move  in  the  simulation  will  be  interdicted. 


RES:  Have  loaded  interdiction  values  for  this  Cl  by 
Initializing  zone  1  and  zone  2  counters 


ANS:  END 

RES:  datums  to  full  contra’  menu  or  I’tarnatv/es 
7JE:  ''I'  -  EDT  DATA 

-  ,r:*e  RE'CR* 

(3)  -  SCHEDULE  CONTROL 

(4)  -  RETURN 

(5)  -  STOP  SIMULATION  NOW 

(6)  -  EDIT  TRUCK  QUEUES 

(7)  -  CREATE  EVENTS 
ANS:  3 

CUE:  Enter  time  to  stop  simulation 
ANS:  480.05 

RES:  At  time  480.05  minutes  ARM  will  return  to  the  control  routine 
RES:  Returns  to  full  menu 
ANS:  4 

RES:  Return  to  process  the  events  for  this  Cl 
CUE:  HAVE  FINISHED  RDJIFF 
ANS:  N/A  (information  only) 

RES:  N/A 

CUE:  Scheduled  stop  at  480.05.  Returns  to  full  menu  of  alternatives. 
ANS:  2 

RES:  Asks  for  report  type,  see  Annex  II. 

RES:  After  printing  last  report,  program  returns  to  full  menu  of 
alternatives. 

ANS:  4 
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CUE:  SCHEDULED  STOP.  TIME  *  480.1 


ANS:  N/A  ' INFORMATION  ONLY) 

RES:  Cl  processing  has  been  competed.  T1  contains  -esu’tinc  data  base 
and  T2  contains  unprocessed  events,  both  o*  which  are  input  for  the  next 
Cl.  Subsequent  CIs  are  -un  as  CI2  but  with  different  times  for  TC 1ST . 
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ANNEX  A- I 


(3) 

IRSTME 

:3) 

IATPSD 

' « > 

.  j 

:day 

•  * «  - 

(12) 

ICSA 

(13) 

LPPAR 

(14) 

IASPAM 

(15) 

LUOUT 

(16) 

TCI  ST 

(17) 

TCILNG 

(18) 

LOOK 

c.  Definition  of  each  common  is  at  Annex  V.  Each  common  has  two 
ordered  subscripts,  I  and  J.  The  I  is  the  ENTITY  number;  e.g.,  the  unit 
number,  the  truck  number,  or  the  ATP  number.  The  J  is  the  ATTRIBUTE,  which 
could  be  the  truck  type  or  truck  speed,  describing  the  entity. 

d.  The  functions  that  can  be  performed  by  the  edit  routine  are  as 
follows: 


(1)  List  present  values. 

(2)  Change  present  values  for  the  run  only. 

e.  The  next  cue  is  .  . 

f.  The  functions  to  be  entered  are  as  follows: 

(1)  L  or  LIST  enables  the  listing  of  present  values  of  an 
attribute  or  attributes.  For  example: 


CUE: 

ANS: 


VARIABLE  NAME 
ITRUCK  17 


RES:  ITRUCK  17 


t 


ATTRIBUTE  2  =  (VALUE) 

CUE:  .  . 

ANS:  IUNIT  22  24 

CUE:  .  . 

ANS:  L  5  6 

RES:  IUNIT  22 

ATTRIBUTE  5  *  (VALUE) 

ATTRIBUTE  6  *  (VALUE) 

IUNIT  23 

ATTRIBUTE  5  =  (VALUE) 

ATTRIBUTE  6  =  (VALUE) 

IUNIT  24 

ATTRIBUTE  5  *  (VALUE) 

ATTRIBUTE  6  -  (VALUE) 

(2)  C  enables  the  changing  of  present  values.  For  exanple: 

(a)  Cue:  VARIABLE  NAME  * 

ANS:  ITRUCK  17 
Cue:  .  . 

ANS:  C  4  5 

RES:  ITRUCK  (17,  4)  »  5 

(b)  Cue:  VARIABLE  NAME 

ANS:  ITRUCK 
.  .  C  6  0 

-  "  RES  (ITRUCK  (I,  J),  >1,  560,  J»6)  «  0 
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ANNEX  A- I I 


ARM  REPORTS 

A-II-1.  PURPOSE.  This  annex  describes  the  reports  available  from  the  ARM 
software. 

A- II -2.  GENERAL. 

a.  Reports  can  be  called  from  any  control  event  when  the  cue  is: 

(1)  EDIT  DATA 

(2)  WRITE  REPORT 

(3)  SCHEDULE  CONTROL 

(4)  RETURN 

(5)  STOP  SIMULATION  NOW 

(6)  EDIT  TRUCK  QUEUES 

(7)  CREATE  EVENTS 

ANS:  2 

CUE:  ENTER  REPORT  TYPE  *  (1,  2,  3,  4,  5,  6,  7,  8,  9) 

ALTERNATIVE  1  Truck  Report 
♦ANS:  I 

CUE:  1  -  PRINT  ALL 

2  -  SINGLE  UNIT 

3  -  RETURN 

SUB-ALTERNATIVE  1 
ANS:  1 

RES:  Produces  a  report  of  all  unit  trucks  assigned  to  units  having  a  non-zero 
unit  type  attribute  (IUNIT  (1,1)  a  non-zero  JIFFY  name  attribute  (IUNIT  (1,7)). 
Sample  report  is  at  tab  1  to  Annex  II. 

SUB-ALTERNATIVE  2 
ANS:  2 

CUE:  ENTER  JIFFY  UNIT  ID 
ANS:  (JIFFY  UNIT  ID) 

RES:  Report  is  printed  for  one  unit  only 


f 


SU8-ALTERNATIVE  2 
ANS:  3 

RES:  Returns  control  to  control  event  and  menu  'n  A- 1 1  -  2  a  above. 

41  teroat'/e  2  Unit  Reoort 
♦ANS:  2 

:u e :  :  -  -Rir  al_ 

2  -  SINGLE  J N I ” 

3  -  RETURN 

SUB-ALTERNATIVE  1 
ANS:  1 

RES:  Prints  all  active  units  and  returns  to  menu  in  A-II-2a.  above. 
SUB-ALTERNATIVE  2 
ANS:  2 

CUE:  ENTER  JIFFY  UNIT  ID 
ANS:  (JIFFY  UNIT  ID) 

RES:  Report  is  printed  for  one  unit  only.  (Tab  2  to  Annex  II) 

CUE:  1  -  PRINT  ALL 

2  -  SINGLE  UNIT 

3  -  RETURN  -• 

SUB-ALTERNATIVE  3 

ANS:  3 

RES:  Returns  control  to  control  event  and  menu  in  A-II-2a.  above. 

ALTERNATIVE  3  ATP  Report 
♦ANS:  3 

CUE:  ENTER  NUMB  OF  ACTIVE  ATPS  (1,2,3,  or  4) 

ANS:  1 

RES:  Will  print  sunmary  data  on  1  ATP  (tab  3  to  Annex  II)  and  returns  to  the 
menu  in  A- I I -2a  above. 

ALTERNATIVE  4 
♦ANS:  4 

CUE:  ENTER  NUMBER  OF  ACTIVE  ASPS,  1,2,3,  or  4 
ANS:  1 

RES:  Prints  report  for  1  ASP  (tab  4  to  Annex  II)  and  returns  to  the  menu  in 
A-II-2a  above. 

ALTERNATIVE  5  CSA  Report 

♦ANS:  5 

RES:  Prints  report  (tab  5  to  Annex  II)  on  how  many  rounds  by  round  type  have 
been  drawn  from  the  CSA  and  returns  to  the  menu  at  A- I I -2a. 

ALTERNATIVE  6  Multiple  ATP  Report 

♦ANS:  6 

RES:  Produces  a  sunmary  report  (tab  5  to  Annex  II)  containing  information 
summarized  across  all  ATPs  and  returns  to  the  menu  at  A-II-2a. 
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ALTERNATIVE  7  Ammo  Removed  from  ASP  Report 

*ANS:  7 

RES:  °rints  a  report  'tab  7  to  Annex  II)  containing  summary  information  across 
all  ASPs  and  returns  to  the  menu  at  A- I I -2a. 

ALTERNATIVE  2  T-ucks  < : 7 1 ed  and/or  Broken  Down 
*ANS:  S 

RES:  Prints  a  report  'tab  8  to  Annex  II)  containing  a  list  of  all  trucks  whose 
status  equals  seven  (killed  by  interdiction)  or  six  (down  for  remedial 
maintenance)  and  returns  to  the  menu  in  A- I I -2a. 

ALTERNATIVE  9  All  Reports 

*ANS'  9 

CUE:’  1  -  PRINT  ALL 

2  -  SINGLE  UNIT 

3  -  RETURN 

ANS:  (See  ALTERNATIVE  2  above.) 

CUE:  ENTER  NUMB  OF  ACTIVE  ATPS  (1,2,3,  or  4) 

ANS:  (See  Alternative  3  above.) 

CUE:  ENTER  NAME  OF  ACTIVE  ASPS  (1,  2,  3,  or  4) 

ANS:  (See  Alternative  4  above!) 

CUE:  ENTER  NUMB  OF  ACTIVE  ASPS  (1,  2,  3,  or  4) 

ANS:  (See  Alternative  7  above.) 

RES:  Prints  a  copy  of  all  reports  alternatives  1  through  alternative  8  and 
returns  to  the  menu  at  A- I I -2a. 

b.  If  the  value  of  LUOUT  is  set  equal  to  2  in  EDIT  the  reports  will  be 
printed  at  the  CRT.  If  LUOUT  is  set  to  6  the  reports  will  be  written  to  the 
output  file  to  be  printed  at  the  DPFO  if  desired. 
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ANNEX  A- III 


SUBROUTINE  TRKPUT 

A-III-I.  PURPOSE.  This  annex  describes  the  subroutine  TRKPUT  and  its  functic 

A-III-2.  GENERAL.  TRKPUT  enables  interactive  assignment,  unassignment,  0” 
reassignment  of  trucks  to  truck  queues. 

A-III-3.  Process  Menu  as  appears  from  the  control  event  follows: 

a.  CUE:  TIME  *  XXX. XX 

(1)  -  EDIT  DATA 

(2)  -  WRITE  REPORT 

(3)  -  SCHEDULE  CONTROL 

(4)  -  RETURN 

(5)  -  STOP  SIMULTION  NOW 

(6)  -  EDIT  TRUCK  QUEUES 

(7)  -  CREATE  EVENTS 
ANS:  6 

b.  CUE:  COMMAND  EXAMPLES 
GET  3  FROM  35 

PUT  3,  10  IN  105 
LIST  105 
TAKE  ALL  OUT 
END 

ALTERNATIVE  1  -  GET 

Purpose:  GET  removes  one  truck  from  a  queue  and  returns  to  menu  A- II I -3b. 
Examples:  GET  3  FROM  35  removes  truck  number  3  from  queue  number  35. 

G  3  FROM  35  (same  as  above). 

G  3  35  (same  as  above). 

G,  3,  35  (same  as  above). 

ALTERNATIVE  2"-  PUT 

Purpose:  PUT  places  a  single  truck  or  a  continuously  numbered  set  of  trucks  ; 
a  queue  and  returns  to  menu  A-III-3b. 

Examples:  PUT  3,  10  IN  105  (places  trucks  3  through  10  into  queue  105) 

P  3,  10  IN  105  (same  as  above) 

P  3  10  105  (same  as  above) 

P  3,  10,  105  (same  as  above) 

ALTERNATIVE  3  -  LIST 

Purpose:  LIST  displays  the  numbers  of  the  trucks  in  the  queue  and  returns  to 
menu  A-III-3b. 

Examples:  LIST  105  (Lists  the  trucks  in  Queue  105) 

L  105  (same  as  above) 

L,  105  (same  as  above' 


alternat: 
Puroose : 
menu  A- 1 1 

Examo'es: 


al~rnat: 

Purpose: 

Example: 


'/E  A  -  TAKE  ALL  OUT 

TAKE  ALL  OUT  initializes  all  the  truck  queues  and  returns  to 
1-26. 

”AKE  ALL  OUT  'Initializes  all  truck  Oueuas)' 
r  {same  as  abovei 

7 E  3  -  END 

Returns  to  control  event  and  the  first  menu  in  A- II I  above. 
END  (returns  to  the  first  menu  in  A- I I 1-3  above). 
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ANNEX  A- IV 


subroutine  creevt 

A-IV-1.  PURPOSE.  This  annex  describes  the  subroutine  create  event 
(CREEVT;  and  its  function. 


A-IV-2.  GENERAL.  CREEVT  enaoles  the  building  of  events  to  occur  later 
within  the  simulation.  The  17  event  types,  their  parameters,  and  a  brief 
description  of  each  are  listed  below: 


Event  Type 

Parameters  (Up  to  5  possible) 

Description 

1  -  Demand 

Unit  Number 

Checks  the  ammo 
demand  of  units. 

2  -  Reload 

Unit  Number 

Replaces  ammo  rounds 
at  unit  weapons 

3  -  UNTDEP 

Unit  Number,  Truck  Number 

Departure  of  empty 
arrmo  truck  from  unit. 

4  -  ATPARV 

Unit  Number ,  Truck  Number, 

Arrival  of  unit  truck 

— 

ATP  Number 

-  at  ATP 

5  -  ASPARV 

Unit  Number,  Truck  Number, 

Arrival  of  unit  truck 

ASP  Number 

at  ASP 

6  -  ATP 

Type  Queue,  ATP  Number 

Process  unit  truck 
at  ATP 

7  -  ASP 

Type  Queue,  ASP  Number 

Process  unit  truck 
at  ASP 

8  -  UNTAR V 

Unit  Number,  Truck  Number 

Arrival  of  unit 
truck  at  UNIT 

9  -  CSAARV 

ATP  or  ASP  Number,  Truck 

Arrival  of  Truck  at 

Number,  ATP-ASP  Flag 

CSA 

10  -  ATPAR1 

ATP  Nuflfcer,  Truck  Number 

Arrival  of  CSA  Truck 
at  ATP 

11  -  ATPAR2 

ATP  Number,  Truck  Number 

Arrival  of  ASP  Truck 
at  ATP 

12  -  ASPAR1  “ 

ATP  Number,  Truck  Number, 

Arrival  of  ASP  Truck 

ASP  Number 

at  ASP 

13  -  HELARV 

Unit  Nuntoer,  Truck  Number 

Arrival  of  Hel icooter 
at  Unit 

14  -  HASPAR 

Empty,  Truck  Nunfcer 

Arrival  of  Helicopter 
at  ASP 

15  -  REPORT 

Report  Number 

Prints  Report 

16  -  CONTRL 

TIME 

Prints  Menu  in  A-IV-3 

17  -  ENDSIM 

NONE 

Writes  events  to 

Mass  Storage 

A- 1 7-3  PROCESS .  the  menu  as  it  appears  in  the  control  event  follows: 


'll  -EDIT  DATA 
'2'  -  /iR:"2  RSPOR” 

'31  -  SCHEDULE  CONTROL 

y  -  RrcR'i 

■  5 ■  -  s-qp  s :mula~:cn  ncw 

(5)  -  EDIT  TRUCK  QUEUES 

(7)  -  CREATE  EVENTS 

? 

ANS:  1 

CUE:  TO  CREATE  AN  EVENT,  INPUT  AS  A  SROUP  SEPARATED  BY  COJfWS  OR  SPACES 

THE  FOLLOWING  7  VALUES:  EVENT  TYPE  (INTEGER  VALUES  BETWEEN  1  AND 
17)  5  PARAMETERS  FOR  EACH  EVENT  (INTEGER,  DEPEND  ON  EVENT  TYPE)  AND 
TIME  (DECIMAL  MINUTES,  REAL)  EXAMPLE:  10,  1,  512,  0,  90,  305. 
CSA-TO-ATP  TRUCK  512  WILL  ARRIVE  AT  ATP  AT  TIME  *  305  MIN. 

Sub-alternative  1 
ANS:  END 

RES:  Reijrns  to  the  control  menu  above. 

Sub-alternative  2 
ANS:  HaP 

RES:  Returns  to  line  5  of  CUE  In  A- IV- 3  above. 

Sub-alternative  3 

Enter  the  events  to  be  processed. 
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ANNEX  A-V 


DATA  COMMONS 

A-V-l.  DUR°OSE.  This  annex  describes  the  contents  of  tne  data  cormions  of 
the  ARM  software. 

A-V-2.  GENERAL.  The  software  requires  space  to  store  descriptive  data  to 
simulate  the  ammunition  resupply.  Four  labeled  common  areas  are  used: 

LOG,  EVENTS,  QUENUM,  and  QUEPNT.  Within  the  labeled  common  areas  are  a 
number  of  groups  of  specifically  related  data.  The  following  is  a  field 
by  field  definition  of  the  grouped  data  sets: 

A-V-3.  I ATP  (4,30) 

4  ATP's 

30  words  each  as  follows: 

1.  Distance  to  CSA 

2.  Distance  to  ASP 

3.  UTM  Coordinate 

4.  Number  of  helicopter  missions  scheduled  in  total  simulation 

5.  Empty 

6.  Associated  ASP  nunfcer 

7 .  Empty 

8.  A  flag  that  =  0  if  arty  queue  has  not  served  a  truck  this  war,  1 
otherwise 

9.  Number  artillery  servers  active 

10.  Nunter  maneuver  unit  servers  active 

11.  Artillery  queue  number 

12.  Maneuver  unit  queue  number 

13.  A  flag  that  =  0  if  mnvr  queue  has  not  served  a  truck  this  war,  1 
otherwise 

14.  Number  trucks  in  artillery  queue 

15.  Number  trucks  in  maneuver  unit  queue 

16.  Current  amno  supply,  ammo  1 

17.  Queue  ammo  demand,  ammo  1 

18.  Basic -anrTo  level,  ammo  1 

19-21  ,  ammo  2 

22-24  ,  airmo  3 

25-27  ,  ammo  4 

28-30  ,  ammo  5 

A-V-4.  IATPSD  (5)  —  ATP  Service  Data 

1.  Max  servers 

2.  Threshold  1  for  queue  1 

3.  Threshold  2  for  queue  1 

4.  Threshold  1  for  queue  2 

5.  Threshold  2  for  queue  2 


A- 7-5.  IAS?  '4,411 

4  ,ASP 

41  rfords  aach  as  'o1 ’ ows : 

1.  Distance  to  ISA 

2.  2' stance  to 

3.  J~M  cocrd’nata 

4 .  Etc ty 

5.  'tumcsr  cruccs  to  ISA 

6.  A  flag  that  3  0  if  a  routine  queue  has  not  served  a  truck  this  war,  1 
otherwise. 

7.  Number  routine  servers  active 

8.  Number  GSRS  servers  active 

9.  Routine  queue  number 

10.  GSRS  queue  number 

11.  A  flag  that  *  0  if  a  GSRS  queue  has  not  served  a  truck  this  war,  1 
otherwise 

12.  Number  trucks  in  routine  queue 

13.  Number  trucks  in  GSRS  queue 

14.  Current  anuio  supply,  ammo  1 
15-33.  Ammo  2-20 

34-41 .  Empty 

A-V-6.  I  AS  PAM  (4,20)  AWO  REMOVED  FROM  ASP 

4  ASP,  20  AWO  TYPES 

A-V-7 .  IUNIT  (75,59) 

75  Units 

69  Words  each  as  follows: 

1.  Type 

2.  ATP  number 

3.  ASP  number 

4.  Distance  to  ATP 

5.  Distance  to  ASP 

6.  UTM  coordinate 

7.  Unit  name 

3.  First  amo  type 

9.  Number  weapons  alive,  First  anmo  type 

10.  Number  weapons  short  ammo.  First  ammo  type 

11.  Number  rounds  short,  (wpns)  First  anmo  type 

12.  Current  ammo  supply,  (wpns)  First  ammo  type 

13.  Routine  resupply  level,  (per  wpn)  First  anmo  type 

14.  Critical  resupply  level,  (per  wpn)  First  ammo  type 

15.  Basic  Ammo  level,  (per  wpn)  First  anuio  type 

16.  Ammo  on  trucks  First  ammo  type 

17.  Number  of  weapons  killed  during  Cl,  1st  anuio  type 

18.  Number  of  weapons  short  ammo  First  anno  type 

19.  Total  rounds  short  through  whole  Cl  First  anmo  type 

20-31  ,  Second  ammo  type 


A-V-2 


32-43 

,  Third  arnno  type 

44-55 

,  Fourth  ammo  type 

56-67 

,  Fifth  anno  type 

68.  Number 

of  helicopters  assigned 

69.  =0  if 

single  pulse  demand  per  Cl 

*  I  if  multiple  pulses  per  Cl 


IR3TME  (20,3}  —  resupply  time  data 

20  types  of  ammo 
3  words  each  as  follows 

1.  Weapon  set-up  time 

2.  Load  time  per  round 

3.  Travel  time  to  weapon 

ITRUCK  (560,7) 

560  trucks 

7  words  each  as  follows: 

1.  Truck  type 

2.  Mission  type 

3.  Status  type 

4.  Owner  number 

5.  Ammo  mix  number 

6.  Percent  loaded 

7.  Time  since  last  failure 

A-V-8.  I TYPE  (6,6) 

6  types  of  trucks 

6  words  for  each  type  truck  as  follows: 

1.  Secondary  road  night  speed  (unit  to  ASP,  ATP) 

2.  Secondary  road  day  speed  (unit  to  ASP,  ATP) 

3.  Highway  night  speed 

4.  Highway  day  speed 

5.  MTBF 

6.  MTTR 


A-V-9.  Truck  Queues: 

1  -  75 
101  -  104 
105  -  108 
109  -  112 
113  -  116 
117  -  120 
121  -  124 
125  -  128 
129  -  132 
133  -  136 


QUEUE  TYPE: 


1 

At 

each 

uni 

2 

At 

AT  PS 

for 

3 

At 

ATPS 

for 

4 

At 

AT  PS 

for 

5 

At 

ATPS 

for 

6 

EMPTY 

7 

At 

ASPS 

for 

8 

At 

ASPS 

for 

9 

At 

ASPS 

for 

10 

EMPTY 

CSA-ATP  trucks 
ASP-ATP  trucks 
unit  artillery  server 
unit  maneuver  server 

CSA-ASP  trucks 
routine  server 
GSRS  server 
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I  o  » 


A-V-ll.  Event  scheduling 

Comnon/Events/ JSTAT ( 6 ) ,  JE'/OS  (1024,4),  IEVS  (5,1024) 
A-V-12.  QUEUE  DATA 

COMMON/QUENUM/IHEAO  (136) 
COMMON/QUEPNT/ITEMS  (560) 

A-V-13.  Interdiction  Data  -  Common  Inter  (9) 

1.  Counter  for  zone  1  trucks  killed  in  intrdk 

2.  Counter  for  zone  2  trucks  killed  in  intrdk 

3.  Number  of  trucks  to  be  killed  in  zone  1 

4.  Number  of  trucks  to  be  killed  in  zone  2 

5.  Time  to  replace  truck  in  zone  1  " 

6.  Time  to  replace  truck  in  zone  2 

7.  Modulo  of  trucks  to  be  killed  in  zone  1  and  zone  2 

8.  Number  of  zone  one  trucks  entering  intrdk 

9.  Number  of  zone  two  trucks  entering  intrdk 

73/73  0PT-1  FTN  4.6+460 


A-V-14.  I DAY:  1  *  Day  ,  0  *  Night 

A-V-15.  ICSA  (20)  —  Number  of  rounds  by  aumo  type  from  CSA 

A-V-16.  LPPAR(5) 

IPPAR(l)  —  Total  number  of  anwo  codes  (20) 

LPPAR(2)  —  Number  of  ammo  codes  at  ATP  (5) 

LPPAR(3)  —  Number  of  maneuver  unit  a/imo  codes  at  ATPi2) 
LPPAR(4)  —  Number  of  transports  ( trucks) (Lt  560) 
LPPAR(5)  —  Number  of  helicopters  available 

A-V-17.  TCIST  —  Time  of  start  of  Cl  in  decimal  minutes 

A-V-18.  TCIING  —  Time  of  length  of  Cl  in  decimal  minutes 

A-V-19.  Time  —  Simulation  time  in  minutes  (decimal) 


A-V-4 


A-V-20.  Unit  Type  Codes: 

1  Tank  Task  Force 

2  Mech  Task  Force 

3  Armrd  Cav  Sqdn 

A  155  Arty  Btry 

5  3  Inch  Arty  Btry 

6  GSR  S  Btry 

7  Divad  Gun  Pit 

8  Cbt  Avn  Pit 


A-V. 

-21.  Truck  type  codes: 

1 

10  Ton 

2 

5  Ton 

3 

5  Ton  with  1  1/2  ton  trailer 

4 

10  ton  with  15  ton  trailer 

5 

22  1/2  ton  stake  &  platform 

6 

helicopter 

A-V- 

22.  Anno  type  codes: 

1 

105mm  (M60-A3/XM1 

2 

TOW 

3 

Powder  Canisters 

4 

155  HE 

5 

155  ICMOP 

6 

155  Smoke 

7 

155  CLGP 

8 

8  Inch  HE 

9 

8  Inch  ICMDP 

10 

GSRS 

11 

Mortar 

12 

DIVAO 

13 

hellfire 

14 

XR-TOW 

15 

STINGER 

16 

DRAGON 

17 

BUSNMASTER 

18 

EMPTY 

19 

EMPTY 

20 

EMPTY 

A-V- 23.  Truck  Mission  Type  Codes: 

1 

Unit  truck 

2 

CSA  -  ATP  Link 

3 

CSA  -  ASP  Link 

4 

ASP  -  ATP  Link 

5 

ASP  -  Unit  (Helicopter) 

-V-24.  Truck  Status  Tyve  Codes: 

IN  Unit  Queue 
IN  AT3  Queue 
IN  AS?  Queue 
IN  MANSI' 

Unit  truck  going  f*om  AT?  to  ASP 
~-uc:<  iwa't'rg  -aoe*- 
>uck  teaa  ' -rtard'ctea' 
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